From: | Manfred Koizar <mkoi-pg(at)aon(dot)at> |
---|---|
To: | Jochem van Dieten <jochemd(at)oli(dot)tudelft(dot)nl> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: planner/optimizer question |
Date: | 2004-04-30 21:36:58 |
Message-ID: | toe590tgu39ilahg3p1os2mjlgf4iss582@email.aon.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Fri, 30 Apr 2004 19:46:24 +0200, Jochem van Dieten
<jochemd(at)oli(dot)tudelft(dot)nl> wrote:
>> While the storage overhead could be reduced to 1 bit (not a joke)
>
>You mean adding an isLossy bit and only where it is set the head
>tuple has to be checked for visibility, if it is not set the head
>tuple does not have to be checked?
Yes, something like this. Actually I imagined it the other way round: a
visible-to-all flag similar to the existing dead-to-all flag (search for
LP_DELETE and ItemIdDeleted in nbtree.c).
>> we'd
>> still have the I/O overhead of locating and updating index tuples for
>> every heap tuple deleted/updated.
>
>Would there be additional I/O for the additional bit in the index
>tuple (I am unable to find the layout of index tuple headers in
>the docs)?
Yes, the visible-to-all flag would be set as a by-product of an index
scan, if the heap tuple is found to be visible to all active
transactions. This update is non-critical and, I think, not very
expensive.
Deleting (and hence updating) a tuple is more critical, regarding both
consistency and performance. We'd have to locate all index entries
pointing to the heap tuple and set their visible-to-all flags to false.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-05-01 01:19:39 | Re: planner/optimizer question |
Previous Message | Kris Jurka | 2004-04-30 19:48:32 | Re: planner/optimizer question |