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

Re: Single Index Tuple Chain (SITC) method

From: Hannu Krosing <hannu(at)skype(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>,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:59:26
Message-ID: 1151600366.5092.3.camel@localhost.localdomain (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Ühel kenal päeval, N, 2006-06-29 kell 12:35, kirjutas Tom Lane:
> 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.

How can it generate more traffic ? 

When you replace a dead index entry with a live one, you just reuse
space - you would have to WAL log the index in both cases (adding a new
entry or replacing dead entry)

Espacially in the case, where you replace an index entryu with the same

Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me:  callto:hkrosing
Get Skype for free:

In response to

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2006-06-29 17:08:33
Subject: Longer startup delay (was Re: Single Index Tuple Chain (SITC) method)
Previous:From: Martijn van OosterhoutDate: 2006-06-29 16:47:17
Subject: Re: [GENERAL] UUID's as primary keys

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