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

Re: Single Index Tuple Chain (SITC) method

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Hannu Krosing <hannu(at)skype(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Greg Stark <gsstark(at)mit(dot)edu>, PFC <lists(at)peufeu(dot)com>
Subject: Re: Single Index Tuple Chain (SITC) method
Date: 2006-06-29 16:35:12
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Martijn van Oosterhout <kleptog(at)svana(dot)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

In response to


pgsql-hackers by date

Next:From: Thomas HallgrenDate: 2006-06-29 16:40:13
Subject: Re: [GENERAL] UUID's as primary keys
Previous:From: Jim C. NasbyDate: 2006-06-29 16:32:56
Subject: Re: Fixed length datatypes. WAS [GENERAL] UUID's as

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