Bruce Momjian <[EMAIL PROTECTED]> writes:
> I agree we don't want anything that is O(high), but I was thinking of
> something that would be more agressive than 1%, which works well for
> lots of self joins, but I am not sure how well for other cases.
That assumption is without foundation. The pa
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Right. There are potentially some ranges of LIMIT for which it could
> >> win, I believe.
>
> > What if we take the total cost and divide it by the number of rows returned ---
> > then we have a per-row cost for
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Right. There are potentially some ranges of LIMIT for which it could
>> win, I believe.
> What if we take the total cost and divide it by the number of rows returned ---
> then we have a per-row cost for each plan. Then we subtract th
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Do we know in the optimizer whether we will be needing cheapest startup
> > or not?
>
> No. Higher levels might want either.
>
> > Is the middle one kept because the optimizer has to mix the startup plus
> > some percentage of the t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Do we know in the optimizer whether we will be needing cheapest startup
> or not?
No. Higher levels might want either.
> Is the middle one kept because the optimizer has to mix the startup plus
> some percentage of the total cost for queries using LIMI
Tom Lane wrote:
> The reason these are all being kept is that add_path() will keep paths
> of the same ordering (same pathkeys) if they rank differently on startup
> cost than they do on total cost. Now that's a good rule in the
> abstract, but a human looking at these numbers would certainly say
Neil Conway wrote:
On 28-Mar-04, at 8:32 PM, Joe Conway wrote:
> + * XXX does this percentage need to be user-configurable?
...but I think the answer to the above is yes.
Is this really a parameter that we can expect administrators to be able
to understand and tune very effectively?
I think
On 28-Mar-04, at 8:32 PM, Joe Conway wrote:
It looks like a great idea to me...
> + * XXX does this percentage need to be user-configurable?
...but I think the answer to the above is yes.
Is this really a parameter that we can expect administrators to be able
to understand and tune very effect
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>>> +* XXX does this percentage need to be user-configurable?
> ...but I think the answer to the above is yes.
I'd want to see some evidence that there's use in twiddling it ...
in my initial test, setting it to 10% instead of 1% didn't
Tom Lane wrote:
As an experiment, I made the attached patch that converts add_path's
cost comparisons to "fuzzy" comparisons --- two paths are considered to
have the same cost if it differs by less than 1% of the smaller
total_cost. I found that this reduced the planning time of Eric's
query by ab
Mike Mascari <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>>> I found that this reduced the planning time of Eric's
>>> query by about 40%, without changing the resulting plan.
> More great news, as always. IIRC you recently bumped the default
> GEQO threshold from eleven to twelve. With your ne
Tom Lane wrote:
I've been looking at the planner performance problem exhibited by
Eric Brown:
http://archives.postgresql.org/pgsql-performance/2004-03/msg00273.php
While a nine-way join is inherently going to take some time to plan
(if you don't constrain the search space with JOIN), it seemed to m
I've been looking at the planner performance problem exhibited by
Eric Brown:
http://archives.postgresql.org/pgsql-performance/2004-03/msg00273.php
While a nine-way join is inherently going to take some time to plan
(if you don't constrain the search space with JOIN), it seemed to me
that this par
13 matches
Mail list logo
