Re: R: R: slow seqscan after vacuum analize - Mailing list pgsql-admin

From Tom Lane
Subject Re: R: R: slow seqscan after vacuum analize
Date
Msg-id 4193.1076000989@sss.pgh.pa.us
Whole thread Raw
In response to Re: R: R: slow seqscan after vacuum analize  (Christopher Browne <cbbrowne@acm.org>)
Responses Drop indexes inside transaction?  (Steve Lane <slane@moyergroup.com>)
List pgsql-admin
Christopher Browne <cbbrowne@acm.org> writes:
> Another factor worth considering: If a few values are very common in
> the field you are selecting on, then the query optimizer can get
> convinced (wrongly) that a Seq Scan is the best choice.  Using ALTER
> TABLE T ALTER COLUMN C SET STATISTICS [some value] to increase the
> number of "bins" can be helpful in such cases.  (My pet theory is that
> the present default value of 10 is a little low, and that a lot of
> optimizer errors might be resolved by bumping it up a bit...)

I also suspect that 10 is a lowball figure, but no one has done any work
to establish what might be a more reasonable default.  Larger values
have real costs in both pg_statistic space and planner runtime, so I
don't want to push it up without some kind of evidence.

BTW, if you think a higher default might be appropriate, you can set it
in postgresql.conf instead of running around and manually ALTERing all
your tables.

            regards, tom lane

pgsql-admin by date:

Previous
From: "Stefan Sturm"
Date:
Subject: VACUUM Quesition
Next
From: Sam Barnett-Cormack
Date:
Subject: Re: VACUUM Quesition