Re: Really really slow select count(*)

Поиск
Список
Период
Сортировка
От Shaun Thomas
Тема Re: Really really slow select count(*)
Дата
Msg-id 4D4C3B32.8070607@peak6.com
обсуждение исходный текст
Ответ на Re: Really really slow select count(*)  (felix <crucialfelix@gmail.com>)
Список pgsql-performance
On 02/04/2011 11:38 AM, felix wrote:

> CPU 0.00s/0.00u sec elapsed 0.00 sec.
> INFO:  analyzing "public.fastadder_fastadderstatus"
> INFO: "fastadder_fastadderstatus": scanned 2492 of 2492 pages,
> containing 154378 live rows and 0 dead rows; 30000 rows in sample,
> 154378 estimated total rows
>
> and there's nothing at the end of the whole vacuum output about pages

I'm not sure if it gives it to you if you pick a single DB, but if you
use -a for all, you should get something at the very end like this:

INFO:  free space map contains 1365918 pages in 1507 relations
DETAIL:  A total of 1326656 page slots are in use (including overhead).
1326656 page slots are required to track all free space.
Current limits are:  3000000 page slots, 3500 relations, using 38784 kB.
VACUUM

That's on our dev system. Your dev table seems properly sized, but prod
probably isn't. If you run an all-database vacuum after-hours, you'll
see the stuff at the end. And if your 'page slots are required' is
greater than your 'page slots are in use,' you've got a problem.

--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 800 | Chicago IL, 60604
312-676-8870
sthomas@peak6.com

______________________________________________

See  http://www.peak6.com/email_disclaimer.php
for terms and conditions related to this email

В списке pgsql-performance по дате отправления:

Предыдущее
От: felix
Дата:
Сообщение: Re: Really really slow select count(*)
Следующее
От: felix
Дата:
Сообщение: Re: Really really slow select count(*)