From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Blasby <dblasby(at)refractions(dot)net> |
Cc: | Gaetano Mendola <mendola(at)bigfoot(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SELECT * FROM <table> LIMIT 1; is really slow |
Date: | 2004-05-26 22:28:25 |
Message-ID: | 3104.1085610505@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
David Blasby <dblasby(at)refractions(dot)net> writes:
> I just did another vacuum analyse on the table:
Ah, here we go:
> INFO: "csn_edges": found 0 removable, 16289929 nonremovable row
> versions in 2783986 pages
That works out to just under 6 rows per 8K page, which wouldn't be too
bad if the rows are 1K wide on average, but are they? (You might want
to run contrib/pgstattuple to get some exact information about average
tuple size.)
> INFO: analyzing "public.csn_edges"
> INFO: "csn_edges": 2783986 pages, 3000 rows sampled, 6724 estimated
> total rows
This looks like a smoking gun to me. The huge underestimate of number
of rows from ANALYZE is a known failure mode of the existing sampling
method when the early pages of the table are thinly populated. (Manfred
just fixed that for 7.5, btw.)
I think you want to VACUUM FULL or CLUSTER the table, and then take a
look at your FSM settings and routine vacuuming frequency to see if
you need to adjust them to keep this from happening again.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David Blasby | 2004-05-26 23:02:42 | Re: SELECT * FROM <table> LIMIT 1; is really slow |
Previous Message | Tom Lane | 2004-05-26 22:17:55 | Re: SELECT * FROM <table> LIMIT 1; is really slow |