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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Progress on fast path sorting, btree index creation time
Дата
Msg-id CA+Tgmoa=WmJrQYXcrNO=8cibCWvAKZERwNO+b5fLtdDuTvSN8Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Progress on fast path sorting, btree index creation time  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: 16-bit page checksums for 9.2
Следующее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: Add SPI results constants available for PL/*