From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-patches(at)postgreSQL(dot)org> |
Subject: | Re: Proposed fixes for planner regressions from Junetorelease |
Date: | 2006-12-11 21:00:37 |
Message-ID: | 1165870837.3816.113.camel@silverbirch.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
On Mon, 2006-12-11 at 15:33 -0500, Tom Lane wrote:
> "Simon Riggs" <simon(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Ron Mayer | 2006-12-11 21:31:57 | Re: Load distributed checkpoint |
Previous Message | Tom Lane | 2006-12-11 20:33:57 | Re: Proposed fixes for planner regressions from June torelease |