| От | Kevin Grittner |
|---|---|
| Тема | Re: Good News re count(*) in 8.1 |
| Дата | |
| Msg-id | 43FDB09C.EE98.0025.0@wicourts.gov обсуждение |
| Ответ на | Re: Good News re count(*) in 8.1 (Greg Stark <gsstark@mit.edu>) |
| Ответы |
Re: Good News re count(*) in 8.1
|
| Список | pgsql-performance |
>>> On Wed, Feb 22, 2006 at 9:52 pm, in message <87irr6zq7j.fsf@stark.xeocode.com>, Greg Stark <gsstark@mit.edu> wrote: > "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes: > >> There have been several times that I have run a SELECT COUNT(*) on an entire >> table on all central machines. On identical hardware, with identical data, >> and equivalent query loads, the PostgreSQL databases have responded with a >> count in 50% to 70% of the time of the commercial product, in spite of the >> fact that the commercial product does a scan of a non- clustered index while >> PostgreSQL scans the data pages. > > I take it these are fairly narrow rows? The big benefit of index- only scans > come in when you're scanning extremely wide tables, often counting rows > matching some indexed criteria. I'm not sure what you would consider "fairly narrow rows" -- so see the attached. This is the VACUUM ANALYZE VERBOSE output for the largest table, from last night's regular maintenance run. -Kevin
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера