Re: Really really slow select count(*)

From: felix <crucialfelix(at)gmail(dot)com>
To: sthomas(at)peak6(dot)com, pgsql-performance(at)postgresql(dot)org
Subject: Re: Really really slow select count(*)
Date: 2011-02-04 18:14:00
Message-ID: AANLkTikjw46g=VD5vbkOfDz93JMX7vBijj7dTEs+LN4U@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

vacuumdb -a -v -z -U postgres -W &> vacuum.log
Password:
Password:
Password:
Password:
Password:
Password:
Password:
Password:
Password:
Password:
Password:
cruxnu:nsbuildout crucial$

do you think its possible that it just doesn't have anything to complain
about ?
or the password is affecting it ?

In any case I'm not sure I want to run this even at night on production.

what is the downside to estimating max_fsm_pages too high ?

3000000 should be safe
its certainly not 150k

I have one very large table (10m) that is being analyzed before I warehouse
it.
that could've been the monster that ate the free map.
I think today I've learned that even unused tables affect postgres
performance.

and do you agree that I should turn CLUSTER ON ?
I have no problem to stop all tasks to this table at night and just reload
it

On Fri, Feb 4, 2011 at 6:47 PM, Shaun Thomas <sthomas(at)peak6(dot)com> wrote:

> On 02/04/2011 11:44 AM, felix wrote:
>
> the very end:
>>
>> There were 0 unused item pointers.
>> 0 pages are entirely empty.
>> CPU 0.00s/0.00u sec elapsed 0.00 sec.
>> INFO: analyzing "public.seo_partnerlinkcategory"
>> INFO: "seo_partnerlinkcategory": scanned 0 of 0 pages, containing 0 live
>> rows and 0 dead rows; 0 rows in sample, 0 estimated total rows
>>
>
> That looks to me like it didn't finish. Did you fork it off with '&' or run
> it and wait until it gave control back to you?
>
> It really should be telling you how many pages it wanted, and are in use.
> If not, something odd is going on.
>
>
> --
> Shaun Thomas
> OptionsHouse | 141 W. Jackson Blvd. | Suite 800 | Chicago IL, 60604
> 312-676-8870
> sthomas(at)peak6(dot)com
>
> ______________________________________________
>
> See http://www.peak6.com/email_disclaimer.php
> for terms and conditions related to this email
>

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Scott Marlowe 2011-02-04 18:33:38 Re: Really really slow select count(*)
Previous Message Shaun Thomas 2011-02-04 17:45:22 Re: Really really slow select count(*)