27.07.2010 21:37, Tom Lane пишет:
Right. Because of the OR, it is *not* possible to conclude that
d2.basedon is always equal to 234409763, which is the implication of
putting them into an equivalence class.
In the example, we do have d1.id and d2.basedon grouped in an
equivalence class. So in
Yeb Havinga writes:
> Robert Haas wrote:
>> On Wed, Jul 28, 2010 at 7:24 AM, Yeb Havinga wrote:
>>> Wouldn't it be relatively easy, to rewrite the filter expression by adding
>>> expressions, instead of replacing constants, in the disjunctive case, so the
>>> example at hand would become:
>>>
>>
Robert Haas wrote:
On Wed, Jul 28, 2010 at 7:24 AM, Yeb Havinga wrote:
Sorry? I though what Equivalence Class provides is the "proving" that
using this qualification or another will *not* affect the output.
In a query like...
SELECT d1.ID, d2.ID
FROM DocPrimary d1
JOIN DocPrim
Robert Haas writes:
> SELECT d1.ID, d2.ID
> FROM DocPrimary d1
>JOIN DocPrimary d2 ON d2.BasedOn=d1.ID
> WHERE (d1.ID=234409763) or (d2.ID=234409763)
>
> ...you're going to scan d1, scan d2, and then join the results. The
> scan of d1 is going to produce different results depending on whet
On Wed, Jul 28, 2010 at 7:24 AM, Yeb Havinga wrote:
>>> Sorry? I though what Equivalence Class provides is the "proving" that
>>> using this qualification or another will *not* affect the output.
>>
>> In a query like...
>>
>> SELECT d1.ID, d2.ID
>> FROM DocPrimary d1
>> JOIN DocPrimary d2 ON
Robert Haas wrote:
On Wed, Jul 28, 2010 at 6:55 AM, Dimitri Fontaine
wrote:
Robert Haas writes:
But here you want to have different paths for
the same relation that generate *different output*, and the planner
doesn't understand that concept.
Sorry? I though what Equivalence
On Wed, Jul 28, 2010 at 6:55 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> But here you want to have different paths for
>> the same relation that generate *different output*, and the planner
>> doesn't understand that concept.
>
> Sorry? I though what Equivalence Class provides is the "p
Robert Haas writes:
> But here you want to have different paths for
> the same relation that generate *different output*, and the planner
> doesn't understand that concept.
Sorry? I though what Equivalence Class provides is the "proving" that
using this qualification or another will *not* affect
On Wed, Jul 28, 2010 at 3:45 AM, Dimitri Fontaine
wrote:
>> Even if we understood how to direct the rewriting process, I'm really
>> dubious that it would win often enough to justify the added planning
>> time. The particular problem here seems narrow enough that solving it
>> on the client side
Tom Lane writes:
> In the example, we do have d1.id and d2.basedon grouped in an
> equivalence class. So in principle you could substitute d1.id into the
> WHERE clause in place of d2.basedon, once you'd checked that it was
> being used with an operator that's compatible with the specific
> equiv
Robert Haas writes:
> On Tue, Jul 20, 2010 at 11:23 AM, Dimitri Fontaine
> wrote:
>> The specific diff between the two queries is :
>>
>> JOIN DocPrimary d2 ON d2.BasedOn=d1.ID
>> - WHERE (d1.ID=234409763) or (d2.ID=234409763)
>> + WHERE (d2.BasedOn=234409763) or (d2.ID=234409763)
>>
>> So th
20.07.2010 18:31, Robert Haas:
According to the EXPLAIN ANALYZE output, your "slow" query is
executing in 0.007 ms, and your "fast" query is executing in 0.026 ms
(i.e. not as quickly as the slow query). Since you mention that it
takes 7 s further down, I suspect this is not the real EXPLAIN AN
On Tue, Jul 20, 2010 at 09:57:06AM +0400, Zotov wrote:
> SELECT d1.ID, d2.ID
> FROM DocPrimary d1
>JOIN DocPrimary d2 ON d2.BasedOn=d1.ID
> WHERE (d1.ID=234409763) or (d2.ID=234409763)
You could try rewriting it to:
SELECT d1.ID, d2.ID
FROM DocPrimary d1
JOIN DocPrimary d2 ON
On Tue, Jul 20, 2010 at 3:33 PM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> On Tue, Jul 20, 2010 at 11:23 AM, Dimitri Fontaine
>> wrote:
>>> JOIN DocPrimary d2 ON d2.BasedOn=d1.ID
>>> - WHERE (d1.ID=234409763) or (d2.ID=234409763)
>>> + WHERE (d2.BasedOn=234409763) or (d2.ID=234409763)
>
Robert Haas writes:
> On Tue, Jul 20, 2010 at 11:23 AM, Dimitri Fontaine
> wrote:
>> JOIN DocPrimary d2 ON d2.BasedOn=d1.ID
>> - WHERE (d1.ID=234409763) or (d2.ID=234409763)
>> + WHERE (d2.BasedOn=234409763) or (d2.ID=234409763)
>
> I was thinking of the equivalence class machinery as well. I
On Tue, Jul 20, 2010 at 11:23 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> All that having been said, I think the issue here is that the query
>> planner isn't inferring that d1.ID= implies d2.ID=> constant>, even though there's a join clause d1.ID=d2.ID.
>
> I think that's what the Equiv
Robert Haas writes:
> All that having been said, I think the issue here is that the query
> planner isn't inferring that d1.ID= implies d2.ID= constant>, even though there's a join clause d1.ID=d2.ID.
I think that's what the Equivalence Classes are for. Or at least that's
what they do in my hea
On Tue, Jul 20, 2010 at 1:57 AM, Zotov wrote:
> i wrote to
> pgsql-b...@postgresql.org
> they tell me write to
> pgsql-performa...@postgresql.org
> they tell me write here
>
> I don`t whant know how optimize query myself (i know it), and i think it
> must do planner.
According to the EXPLAIN
*i wrote to
pgsql-b...@postgresql.org
they tell me write to
pgsql-performa...@postgresql.org
they tell me write here*
*I don`t whant know how optimize query myself (i know it), and i think
it must do planner.*
I have a query:
SELECT d1.ID, d2.ID
FROM DocPrimary d1
JOIN DocPrimary d2
19 matches
Mail list logo
