From: | "Phoenix Kiula" <phoenix(dot)kiula(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Postgres General" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Statistics collection question |
Date: | 2007-09-03 15:24:39 |
Message-ID: | e373d31e0709030824o47cb4944i5b8a9a2dfcdc597b@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 03/09/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Phoenix Kiula" <phoenix(dot)kiula(at)gmail(dot)com> writes:
> most_common_vals will (and should) be empty if there aren't actually any
> common values, but aren't you getting a histogram? Exactly what
> performance do you think will be improved?
Lots of posts here in reponse to performance question have the
recommendation "increase the stats on that column". From whatever
succint reading is made available on the postgres site, I gather that
this aids the planner in getting some info about some of the data. Am
I missing something here, or totally off-base?
The issue is that I don't quite get why MySQL can fetch one indexed
row (i.e., SQL that ends with a very simple "WHERE indexed_column =
'constant' ") in a matter of milliseconds, but PgSQL is taking 5 to 6
seconds on an average at least for the first time. I use RAPTOR 15K
drives, they're not SCSI but they're not exactly "cheap disks" either.
And I have 4GB RAM. The explain select shows that index is being
used!
TIA.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2007-09-03 15:34:13 | Re: Statistics collection question |
Previous Message | Tom Lane | 2007-09-03 15:04:12 | Re: WAL Archiving problem |