Skip site navigation (1) Skip section navigation (2)

Incorrect cursor behaviour with gist index

From: Teodor Sigaev <teodor(at)sigaev(dot)ru>
To: Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: Martin Schäfer <Martin(dot)Schaefer(at)cadcorp(dot)com>
Subject: Incorrect cursor behaviour with gist index
Date: 2008-10-17 18:33:20
Message-ID: 48F8DA70.7010804@sigaev.ru (view raw or flat)
Thread:
Lists: pgsql-hackers
I'm back, sorry for a long absence.

About this bug: http://archives.postgresql.org/pgsql-bugs/2008-09/msg00086.php

Unfortunately, GiST index doesn't work with change direction of scan. I.e. it 
can't move forward then move backward and this behaviour was from the beginning.

I think it's fixable, although GiST doesn't store on page left links (only right 
links) and doesn't store parent page pointer. That's needed because matched 
entries in GiST isn't stored consecutively unlike to BTree. So, price for it 
will be storing in memory or stack all numbers of visited pages in index even 
they will not be used. In worst case it's 2^32 of  GISTSearchStack. Right now it 
occupies 24-32 bytes depending on sizeof(void*), and it will be needed to add 
one more pointer to make double-linked stack. So, about 32Mb. Is it acceptable?

Nevertheless, it doesn't solve problem with concurrent page splitting what can 
cause different order between forward and backward scan in one cursor.

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

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2008-10-17 19:13:19
Subject: Re: Block-level CRC checks
Previous:From: Teodor SigaevDate: 2008-10-17 17:44:25
Subject: Re: small bug in hlCover

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group