Re: Progress on fast path sorting, btree index creation time

From: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Progress on fast path sorting, btree index creation time
Date: 2012-01-06 19:34:03
Message-ID: CAEYLb_VOD7HyMZrmThxN+vWsq-Sz7Xq4rDCxabXcpBJkoUpndg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 6 January 2012 18:45, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Geoghegan <peter(at)2ndquadrant(dot)com> writes:
>> I didn't bother isolating that, because it doesn't really make sense
>> to (not having it is probably only of particular value when doing what
>> I'm doing anyway, but who knows). Go ahead and commit something to
>> remove that code (get it in both comparetup_index_btree and
>> comparetup_index_hash), as well as the tuple1 != tuple2 test now if
>> you like. It's patently clear that it is unnecessary, and so doesn't
>> have to be justified as a performance enhancement - it's a simple case
>> of refactoring for clarity. As I've said, we don't do this for heap
>> tuples and we've heard no complaints in all that time. It was added in
>> commit fbac1272b89b547dbaacd78bbe8da68e5493cbda, presumably when
>> problems with system qsorts came to light.
>
> 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? Even
if you can present an argument for keeping it, it has to weigh the
fact that people don't tend to have much use for indexes with lots of
duplicates anyway. Prior to 2004, we did not do this - it was
justified as insurance against bad qsort implementations only.

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2012-01-06 19:35:01 Re: 16-bit page checksums for 9.2
Previous Message David Fetter 2012-01-06 19:28:28 Re: WIP(!) Double Writes