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

From Robert Haas
Subject Re: Progress on fast path sorting, btree index creation time
Date
Msg-id CA+Tgmoa=WmJrQYXcrNO=8cibCWvAKZERwNO+b5fLtdDuTvSN8Q@mail.gmail.com
Whole thread Raw
In response to Re: Progress on fast path sorting, btree index creation time  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Progress on fast path sorting, btree index creation time  (Josh Berkus <josh@agliodbs.com>)
Re: Progress on fast path sorting, btree index creation time  (Peter Geoghegan <peter@2ndquadrant.com>)
List pgsql-hackers
On Fri, Jan 6, 2012 at 4:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

Obviously, many indexes are unique and thus won't have duplicates at
all.  But if someone creates an index and doesn't make it unique, odds
are very high that it has some duplicates.  Not sure how many we
typically expect to see, but more than zero...

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: 16-bit page checksums for 9.2
Next
From: Martijn van Oosterhout
Date:
Subject: Re: Add SPI results constants available for PL/*