Tom Lane wrote:
> Ryan Bradetich <[EMAIL PROTECTED]> writes:
> > This worked great! Is their a place I can change the default to 3?
> > I do not want to change all the scripts to include this :)
>
> See src/include/optimizer/cost.h. However, I am currently thinking of
> taking Hiroshi's advice
Ryan Bradetich <[EMAIL PROTECTED]> writes:
> This worked great! Is their a place I can change the default to 3?
> I do not want to change all the scripts to include this :)
See src/include/optimizer/cost.h. However, I am currently thinking of
taking Hiroshi's advice instead. Lowering RANDOM_PA
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
>
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > That certainly would make sense. We have hesitated to gather more
> > > statistics because of the time involved. Fuller statistics
> on just the
> > > indexed col
Tom Lane wrote:
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> >> One way to put a thumb on the scales is to reduce the value of the SET
> >> variable random_page_cost. The default value is 4.0, which seems to
> >> correspond more or less to reality, but reducing it to 3 or so would
> >> shift
> Yeah, a scan over just the index itself would be a perfect way to
^
I believe that Oracle updates index statistic on-fly...
Meta-page is always in cache for inserts, so there will be no
additional reads.
> gather stats. The normal objection to it (can't
> > Oracle has index keys distribution page... And we have near empty
> > meta-page for each index AM... And backend reads this page for
> > each insert...
>
> That certainly would make sense. We have hesitated to gather more
> statistics because of the time involved. Fuller statistics
> on ju
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > That certainly would make sense. We have hesitated to gather more
> > statistics because of the time involved. Fuller statistics on just the
> > indexed columns could be a big win and be done fairly quickly because
> > the rows are already sorted i
Jeff Hoffmann <[EMAIL PROTECTED]> writes:
> on another topic, is there a list somewhere of the variables that you
> can adjust with a SET command?
SET command reference page is fairly complete, I think (but if you want
The Whole Truth And Nothing But, see src/backend/commands/variable.c).
Bruce Momjian <[EMAIL PROTECTED]> writes:
> That certainly would make sense. We have hesitated to gather more
> statistics because of the time involved. Fuller statistics on just the
> indexed columns could be a big win and be done fairly quickly because
> the rows are already sorted in the inde
Tom Lane wrote:
> One way to put a thumb on the scales is to reduce the value of the SET
> variable random_page_cost. The default value is 4.0, which seems to
> correspond more or less to reality, but reducing it to 3 or so would
> shift the planner pretty nicely in the direction of indexscans.
[ Charset ISO-8859-1 unsupported, converting... ]
> > For example we could count up distinct values for the first
> > column of an index by scanning its index relation.
>
> Oracle has index keys distribution page... And we have near empty
> meta-page for each index AM... And backend reads this p
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
>> One way to put a thumb on the scales is to reduce the value of the SET
>> variable random_page_cost. The default value is 4.0, which seems to
>> correspond more or less to reality, but reducing it to 3 or so would
>> shift the planner pretty nicely i
> For example we could count up distinct values for the first
> column of an index by scanning its index relation.
Oracle has index keys distribution page... And we have near empty
meta-page for each index AM... And backend reads this page for
each insert...
Vadim
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
> Of Tom Lane
>
[snip]
>
> This seems to point up (once again) the deficiency of assuming that
> the most-common value in the table is a good guide to the frequency
> of typical values. You showed that
Ryan Bradetich <[EMAIL PROTECTED]> writes:
> procman=# explain select count(catagory) from medusa where host_id = 404
> and catagory like 'A%';
> Here is my analysis of the stastics (based on the examples in the
> archive).
> The most common value host_id in the table is 446 with row fraction of
Tom Lane wrote:
> Ryan Bradetich <[EMAIL PROTECTED]> writes:
> > I am in the process of transitioning from postgreSQL 6.5.3 to
> > postgreSQL 7.0. I ran into an issue where a sequential scan
> > is being choosen on postgreSQL 7.0 where an index scan was
> > choosen on postgreSQL 6.5.3.
>
> Since
Ryan Bradetich <[EMAIL PROTECTED]> writes:
> I am in the process of transitioning from postgreSQL 6.5.3 to
> postgreSQL 7.0. I ran into an issue where a sequential scan
> is being choosen on postgreSQL 7.0 where an index scan was
> choosen on postgreSQL 6.5.3.
Since you're complaining, I assume
Tom (Or anyone else who is good with PostgreSQL statistics),
I am in the process of transitioning from postgreSQL 6.5.3 to
postgreSQL 7.0. I ran into an issue where a sequential scan
is being choosen on postgreSQL 7.0 where an index scan was
choosen on postgreSQL 6.5.3.
Note: All tables have be
18 matches
Mail list logo
