Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
But you don't have any cost numbers until after you've done the plan.
Couldn't this work similar to geqo_effort? The planner could
try planning the query using only cheap algorithmns, and if
the cost exceeds a
Tom Lane [EMAIL PROTECTED] writes:
Jim C. Nasby [EMAIL PROTECTED] writes:
How many cycles are we talking about here? Is it even worth the GUC?
I think so. On simple queries the optimization will *never* fire,
and there's no point in doing the search. People who are running
complex
On Fri, 2006-08-04 at 14:40 -0400, Tom Lane wrote:
I was just looking at Martin Lesser's gripe here:
http://archives.postgresql.org/pgsql-performance/2006-08/msg00053.php
about how the planner is not real bright about the filter conditions
it generates for a simple partitioning layout. In
On Mon, 2006-08-07 at 16:54 +0100, Simon Riggs wrote:
On Fri, 2006-08-04 at 14:40 -0400, Tom Lane wrote:
I was just looking at Martin Lesser's gripe here:
http://archives.postgresql.org/pgsql-performance/2006-08/msg00053.php
about how the planner is not real bright about the filter
Rod Taylor [EMAIL PROTECTED] writes:
A simple way of doing this might be to use a minimum cost number?
But you don't have any cost numbers until after you've done the plan.
regards, tom lane
---(end of broadcast)---
TIP 5:
On Mon, 2006-08-07 at 13:44 -0400, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
A simple way of doing this might be to use a minimum cost number?
But you don't have any cost numbers until after you've done the plan.
Isn't it possible to find the cost using the straight forward
Simon Riggs [EMAIL PROTECTED] writes:
To achieve the indexed partition pruning, we'd need
- a way to specify that all constraints are mutually exclusive
- a declarative approach for saying something like arranged in date
sequence
- preferably a way to have this happen at run-time so we can
Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
A simple way of doing this might be to use a minimum cost number?
But you don't have any cost numbers until after you've done the plan.
Couldn't this work similar to geqo_effort? The planner could
try planning the query using only cheap
Florian G. Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
But you don't have any cost numbers until after you've done the plan.
Couldn't this work similar to geqo_effort? The planner could
try planning the query using only cheap algorithmns, and if
the cost exceeds a certain value, it'd
On Mon, 2006-08-07 at 22:01 -0400, Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
But you don't have any cost numbers until after you've done the plan.
Couldn't this work similar to geqo_effort? The planner could
try planning the query using only cheap
I was just looking at Martin Lesser's gripe here:
http://archives.postgresql.org/pgsql-performance/2006-08/msg00053.php
about how the planner is not real bright about the filter conditions
it generates for a simple partitioning layout. In particular it's
generating scans involving
Ühel kenal päeval, R, 2006-08-04 kell 14:40, kirjutas Tom Lane:
I was just looking at Martin Lesser's gripe here:
http://archives.postgresql.org/pgsql-performance/2006-08/msg00053.php
about how the planner is not real bright about the filter conditions
it generates for a simple partitioning
On Fri, Aug 04, 2006 at 02:40:30PM -0400, Tom Lane wrote:
which it seems we ought to be bright enough to notice. In particular
I would argue that turning on constraint_exclusion ought to instruct
the planner to catch this sort of thing, whereas when it's off we
ought not expend the cycles. I
Jim C. Nasby [EMAIL PROTECTED] writes:
On Fri, Aug 04, 2006 at 02:40:30PM -0400, Tom Lane wrote:
I would argue that turning on constraint_exclusion ought to instruct
the planner to catch this sort of thing, whereas when it's off we
ought not expend the cycles. I have a preliminary patch
14 matches
Mail list logo
