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

Re: Single Index Tuple Chain (SITC) method

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 17:33:50
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, Jun 29, 2006 at 12:35:12PM -0400, Tom Lane wrote:
> 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.

Ok, I'm going to suggest something that's either radical, or very dumb:
does this truncation really need to be xlogged? After all, just like
hint bits, nothing is being done that won't be recovered from later if
it doesn't happen. The only possible thing I can imagine is that during
xlog replay you end up trying to add more tuples than appear to fit.
But if you have a vacuum page procedure you could call it again to try
to compress it down.

Then again, perhaps visibility checks are not safe within xlog replay

I'm hoping that overall disk traffic reduces because total disk space
used by tables/indexes reduces.

> 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.

Well, I was only thinking of having the bgwriter do it in the
background, just bfore writing the block to disk. I'm hoping that it
only tries to write out pages not recently used, so hopefully there
would be very little contention there.

And perhaps you can avoid the xlogging for the same reason as I
suggested above.

Have a nice day,
Martijn van Oosterhout   <kleptog(at)svana(dot)org>
> From each according to his ability. To each according to his ability to litigate.

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2006-06-29 18:54:01
Subject: Re: Single Index Tuple Chain (SITC) method
Previous:From: Alvaro HerreraDate: 2006-06-29 17:08:33
Subject: Longer startup delay (was Re: Single Index Tuple Chain (SITC) method)

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