Re: Statistics collection question

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.

In response to

Responses

Browse pgsql-general by date

  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