Re: selects from large tables

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

In response to

Browse pgsql-performance by date

  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