Re: Proposed fixes for planner regressions from Junetorelease - Mailing list pgsql-patches

From Simon Riggs
Subject Re: Proposed fixes for planner regressions from Junetorelease
Date
Msg-id 1165870837.3816.113.camel@silverbirch.site
Whole thread Raw
In response to Re: Proposed fixes for planner regressions from June torelease  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
On Mon, 2006-12-11 at 15:33 -0500, Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.com> writes:

> > Does that change anything? We shy
> > away from indexes on prepared queries too much already, important when
> > the consequence of doing so is an O(N) seqscan rather than an O(logN)
> > indexscan.
>
> Changing that will require far more extensive changes than twiddling a
> few cost estimates.

Of course and I wasn't expecting those changes here. I should have
raised it on -hackers.

> > The cost of initiating an index scan is a cause for concern, but it
> > seems reasonable to get it accurate. I'd like to perform some of that
> > work at planning time, not at scan time, when it is possible for us to
> > do so. Simple indexed, planned queries shouldn't need to pay that cost
> > repeatedly.
>
> Isn't this opinion in direct contradiction to your previous paragraph?
> If you want the thing to be more flexible about plans involving unknown
> parameter values, then you have to push work towards the runtime end,
> not towards the planner.

In general, perhaps, but there are some things that can be done at
planning time, such as deciding on unique scans and analyzing columns
for the scan.

--
  Simon Riggs
  EnterpriseDB   http://www.enterprisedb.com



pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: Proposed fixes for planner regressions from June torelease
Next
From: Andrew Dunstan
Date:
Subject: Re: [HACKERS] psql commandline conninfo