Re: Understanding GIN posting trees - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Understanding GIN posting trees
Date
Msg-id 4E1F4A4D.9040609@enterprisedb.com
Whole thread Raw
In response to Re: Understanding GIN posting trees  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 14.07.2011 22:10, Tom Lane wrote:
> Heikki Linnakangas<heikki.linnakangas@enterprisedb.com>  writes:
>> Why is the posting tree a tree? AFAICS, we never search it using the
>> TID, it's always scanned in whole. It would be simpler to store the TIDs
>> in a posting list in no particular order. This could potentially make
>> insertions cheaper, as you could just append to the last posting list
>> page for the key, instead of traversing the posting tree to a particular
>> location. You could also pack the tids denser, as you wouldn't need to
>> reserve free space for additions in the middle.
>
> Surely VACUUM would like to search it by TID for deletion purposes?

It doesn't, it scans all the tid lists in whole. I guess it could search 
by TID, it could be a win if there's only a few deleted tuples, in a 
small range of pages.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Kohei KaiGai
Date:
Subject: Re: [v9.1] sepgsql - userspace access vector cache
Next
From: "David E. Wheeler"
Date:
Subject: Re: pg_class.relistemp