Skip site navigation (1)
Skip section navigation (2)
Peripheral Links
Re: Progress on fast path sorting, btree index creation time
On Fri, Jan 6, 2012 at 4:14 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
In response to
- Re: Progress on fast path sorting, btree index creation time at 2012-01-06 21:14:27 from Tom Lane
Responses
- Re: Progress on fast path sorting, btree index creation time at 2012-01-09 19:45:39 from Josh Berkus
- Re: Progress on fast path sorting, btree index creation time at 2012-01-19 18:47:10 from Peter Geoghegan
pgsql-hackers by date
Next: From: Martijn van Oosterhout Date: 2012-01-06 22:07:18 Subject: Re: Add SPI results constants available for PL/* Previous: From: Robert Haas Date: 2012-01-06 21:44:02 Subject: Re: 16-bit page checksums for 9.2