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 cer
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 onl
"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,
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
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
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
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
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 co
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
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
>
"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 p
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.
Ü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
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 self-contradicto
14 matches
Mail list logo
