Re: Single Index Tuple Chain (SITC) method - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Single Index Tuple Chain (SITC) method
Date
Msg-id 448.1151598912@sss.pgh.pa.us
Whole thread Raw
In response to Re: Single Index Tuple Chain (SITC) method  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: Single Index Tuple Chain (SITC) method  (Hannu Krosing <hannu@skype.net>)
Longer startup delay (was Re: Single Index Tuple Chain (SITC) method)  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: Single Index Tuple Chain (SITC) method  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers
Martijn van Oosterhout <kleptog@svana.org> writes:
>> Tom - what do you think of the other related idea, that of reusing dead
>> index entries ?

Possibly workable for btree now that we do page-at-a-time index scans;
however I'm pretty hesitant to build any large infrastructure atop that
change until we've got more performance results.  We might yet end up
reverting it.

Another issue is that this would replace a simple hint-bit setting with
an index change that requires a WAL entry.  There'll be more WAL traffic
altogether from backends retail-deleting index tuples than there would
be from VACUUM cleaning the whole page at once --- and it won't cut the
I/O demand from VACUUM any, either, since VACUUM still has to scan the
index.  AFAICS this wouldn't make VACUUM either cheaper or less
necessary, so I'm not sure I see the point.

> I'd like to know about this too, including ideas about truncating
> tuples to just the header.

You can't truncate a tuple to just the header, or at least it's not
going to be very useful to do it, unless you can also move other tuples
to coalesce the free space on the page.  Which means you need a
VACUUM-strength page lock.  If you're trying to do this in foreground
queries, you get into the same performance and deadlock issues I already
mentioned.  And I think the net-increase-in-WAL-traffic point would
apply too, since VACUUM will still need to clean the page when it
removes the header.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: Fixed length datatypes. WAS [GENERAL] UUID's as
Next
From: Thomas Hallgren
Date:
Subject: Re: [GENERAL] UUID's as primary keys