Joseph Shraibman <[EMAIL PROTECTED]> writes:
> These two queries are exactly alike. The first one uses aliases except
> for the order by. The second uses aliases also for the order by. The
> third uses whole names. The third has the behavior I want.
I think you are confusing yourself by leaving
These two queries are exactly alike. The first one uses aliases except
for the order by. The second uses aliases also for the order by. The
third uses whole names. The third has the behavior I want.
Someone please tell me what I am doing wrong. I don't want to have to
use whole names for my quer
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
15 matches
Mail list logo
