| From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
|---|---|
| To: | "Richard Neill" <rn214(at)cam(dot)ac(dot)uk> |
| Cc: | "Matthew Wakeling" <matthew(at)flymine(dot)org>,<jmpoure(at)free(dot)fr>, "PostgreSQL Performance" <pgsql-performance(at)postgresql(dot)org>, "Craig Ringer" <craig(at)postnewspapers(dot)com(dot)au>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: Order by (for 15 rows) adds 30 seconds to query time |
| Date: | 2009-12-02 23:31:26 |
| Message-ID: | 4B16A46E020000250002CFC6@gw.wicourts.gov |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Richard Neill <rn214(at)cam(dot)ac(dot)uk> wrote:
> Regarding pg_statistic, I don't understand how to find the
> relevant rows - what am I looking for? (the pg_statistic table is
> 247M in size).
I think the only relevant rows would be the ones with starelid =
pg_class.oid for a table used in the query, and I think you could
further limit it to rows where staattnum = pg_attribute.attnum for a
column referenced in the WHERE clause or a JOIN's ON clause
(including in the views). To help match them up, and to cover all
the bases, listing the related pg_class and pg_attribute rows would
help.
Hopefully that will allow us to generate the same plan in an
EXPLAIN, and then see how it gets such an overblown estimate of the
result rows.
-Kevin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ashish Kumar Singh | 2009-12-02 23:31:46 | performance while importing a very large data set in to database |
| Previous Message | Richard Neill | 2009-12-02 23:04:31 | Re: Order by (for 15 rows) adds 30 seconds to query time |