From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Charles H(dot) Woloszynski" <chw(at)clearmetrix(dot)com> |
Cc: | Nikk Anderson <Nikk(dot)Anderson(at)parallel(dot)ltd(dot)uk>, "'Stephan Szabo'" <sszabo(at)megazone23(dot)bigpanda(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: selects from large tables |
Date: | 2002-11-18 16:25:27 |
Message-ID: | 29735.1037636727@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
"Charles H. Woloszynski" <chw(at)clearmetrix(dot)com> writes:
> Are you doing vaccums on these tables? I was under the understanding
> that the estimated row count should be close to the real row count
> returned, and when it is not (as it looks in your case), the primary
> reason for the disconnect is that the stats for the tables are
> out-of-date.
The fact that he's using 7.1 doesn't help any; the statistics mechanisms
in 7.1 are pretty weak compared to 7.2.
> Also, do you do any clustering of the data (since the queries are mostly
> time limited)? I am wondering if the system is doing lots of seeks to
> get the data (implying that the data is all over the disk and not
> clustered).
It would also be interesting to try a two-column index ordered the other
way (timestamp as the major sort key instead of ID). Can't tell if that
will be a win without more info about the data properties, but it's
worth looking at.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2002-11-18 16:32:46 | Re: selects from large tables |
Previous Message | Charles H. Woloszynski | 2002-11-18 15:46:11 | Re: selects from large tables |