Re: Incorrect cursor behaviour with gist index

From: Teodor Sigaev <teodor(at)sigaev(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>, Martin Schäfer <Martin(dot)Schaefer(at)cadcorp(dot)com>
Subject: Re: Incorrect cursor behaviour with gist index
Date: 2008-10-17 20:41:58
Message-ID: 48F8F896.8030409@sigaev.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Seems like a lotta work for a partial solution :-(. Probably the path
> of least resistance is to teach the planner that only some index AMs can
> do backwards scan. That would result in a Materialize buffer getting
> placed in front of the query if the user demanded scroll capability,
> but it would cost nothing in the more typical case where backwards scan
> isn't needed.

Probably, it will be a better solution. In this case GiST code could be
simplified - remove support of backward scan (in any case not fully workable)

>
> It should be sufficient to specify this in pg_am, right? Or could the
> opclass or indexkey details affect it?

I don't see any examples where it depends on opclass or index key, that's is a
AM property.

>
> BTW, can GIN do backwards scan?
No, at all.

--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2008-10-17 20:44:25 Re: Hot Standby: First integrated patch
Previous Message Greg Stark 2008-10-17 20:41:52 Re: Block-level CRC checks