Magnus Hagander wrote:
> > > I'm hoping someone can shed some light on these results.
> >
> > Not without a lot more detail on how you *got* the results.
> > What exactly did you do to force the various plan choices?
> > (I see some ridiculous choices of indexscans, for instance,
> > suggesti
Tom Lane wrote:
What exactly did you do to force the various plan choices? (I see some
ridiculous choices of indexscans, for instance, suggesting improper use
of enable_seqscan in some cases.)
Except for forcing a hash with indexes (to show that increased use of
indexes is not necessarily good),
Magnus wrote:
> > > I'm hoping someone can shed some light on these results.
> >
> > Not without a lot more detail on how you *got* the results.
> > What exactly did you do to force the various plan choices?
> > (I see some ridiculous choices of indexscans, for instance,
> > suggesting improper use
> > I'm hoping someone can shed some light on these results.
>
> Not without a lot more detail on how you *got* the results.
> What exactly did you do to force the various plan choices?
> (I see some ridiculous choices of indexscans, for instance,
> suggesting improper use of enable_seqscan i
David Brown <[EMAIL PROTECTED]> writes:
> I'm hoping someone can shed some light on these results.
Not without a lot more detail on how you *got* the results. What
exactly did you do to force the various plan choices? (I see some
ridiculous choices of indexscans, for instance, suggesting imprope
I'm hoping someone can shed some light on these results. The 'factor'
compares the ratios of cost to actual for different plans. Perhaps
nested loops should be given a discount in the planner? The estimates
seem to be out by one and a half orders of magnitude. :(
== QUERY ==
SEL
