Re: Progress on fast path sorting, btree index creation time - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Progress on fast path sorting, btree index creation time
Date
Msg-id 23115.1325884467@sss.pgh.pa.us
Whole thread Raw
In response to Re: Progress on fast path sorting, btree index creation time  (Peter Geoghegan <peter@2ndquadrant.com>)
Responses Re: Progress on fast path sorting, btree index creation time  (Robert Haas <robertmhaas@gmail.com>)
Re: Progress on fast path sorting, btree index creation time  (Peter Geoghegan <peter@2ndquadrant.com>)
List pgsql-hackers
Peter Geoghegan <peter@2ndquadrant.com> writes:
> On 6 January 2012 18:45, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Actually, I'm going to object to reverting that commit, as I believe
>> that having equal-keyed index entries in physical table order may offer
>> some performance benefits at access time.  If you don't like the
>> comment, we can change that.

> Please explain your position. When is this supposed to be useful?

When there are lots of duplicates of a particular indexed value, the
existing code will cause an indexscan to search them in physical order,
whereas if we remove the existing logic it'll be random --- in
particular, accesses to the same heap page can no longer be expected to
be clustered.

Admittedly, I don't have any numbers quantifying just how useful that
might be, but on the other hand you've not presented any evidence
justifying removing the behavior either.  If we believe your position
that indexes don't generally have lots of duplicates, then the code in
question will seldom be reached and therefore there would be no
performance benefit in removing it.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Fix breakage from earlier plperl fix.
Next
From: Robert Haas
Date:
Subject: Re: 16-bit page checksums for 9.2