| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> |
| Subject: | Re: Understanding GIN posting trees |
| Date: | 2011-07-14 19:58:05 |
| Message-ID: | 4E1F4A4D.9040609@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 14.07.2011 22:10, Tom Lane wrote:
> Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David E. Wheeler | 2011-07-14 20:10:53 | Re: pg_class.relistemp |
| Previous Message | Kohei KaiGai | 2011-07-14 19:46:26 | Re: [v9.1] sepgsql - userspace access vector cache |