On Thu, Feb 19, 2009 at 4:53 PM, Tom Lane wrote:
> Greg Stark writes:
>> It's tempting to have Hash cheat and just peek at the node beneath it
>> to see if it's a HashAggregate, in which case it could call a special
>> method to request the whole hash. But it would have to know that it's
>> just
Greg Stark writes:
> It's tempting to have Hash cheat and just peek at the node beneath it
> to see if it's a HashAggregate, in which case it could call a special
> method to request the whole hash. But it would have to know that it's
> just a plain uniquify and not implementing a GROUP BY.
More
On Thu, Feb 19, 2009 at 7:54 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Feb 19, 2009 at 1:20 PM, Tom Lane wrote:
>>> [ back to planner stuff after a hiatus ]
>
>> Well, as I wrote upthread:
>
> What you're actually suggesting is modifying the executor to incorporate
> the unique-ficati
On Thu, Feb 19, 2009 at 3:44 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Feb 19, 2009 at 1:38 PM, Tom Lane wrote:
>>> I'll change the comment. Does this help?
>
>> It's an improvement, but your example above is so helpful in
>> understanding what is going on here that it might be worth
Robert Haas writes:
> On Thu, Feb 19, 2009 at 1:38 PM, Tom Lane wrote:
>> I'll change the comment. Does this help?
> It's an improvement, but your example above is so helpful in
> understanding what is going on here that it might be worth explicitly
> mentioning it in the comment, maybe somethi
On Thu, Feb 19, 2009 at 2:54 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Feb 19, 2009 at 1:20 PM, Tom Lane wrote:
>>> [ back to planner stuff after a hiatus ]
>
>> Well, as I wrote upthread:
>
> What you're actually suggesting is modifying the executor to incorporate
> the unique-ficati
Robert Haas writes:
> On Thu, Feb 19, 2009 at 1:20 PM, Tom Lane wrote:
>> [ back to planner stuff after a hiatus ]
> Well, as I wrote upthread:
What you're actually suggesting is modifying the executor to incorporate
the unique-fication logic into hashjoin and/or mergejoin. Maybe, but
that cod
On Thu, Feb 19, 2009 at 1:20 PM, Tom Lane wrote:
> [ back to planner stuff after a hiatus ]
>
> Robert Haas writes:
>> Right, so maybe I wasn't as clear as I could have been in asking the
>> question. I do understand how it can be a win to unique B and use it
>> as the OUTER relation (jointype J
On Thu, Feb 19, 2009 at 1:38 PM, Tom Lane wrote:
> [ after re-reading the code a bit ]
>
> Robert Haas writes:
>> Cool. On the topic of documentation, I find the following comment in
>> joinrels.c rather impenetrable:
>
>> /*
>> * Do these steps o
[ after re-reading the code a bit ]
Robert Haas writes:
> Cool. On the topic of documentation, I find the following comment in
> joinrels.c rather impenetrable:
> /*
> * Do these steps only if we actually have a
> regular semijoin,
>
[ back to planner stuff after a hiatus ]
Robert Haas writes:
> Right, so maybe I wasn't as clear as I could have been in asking the
> question. I do understand how it can be a win to unique B and use it
> as the OUTER relation (jointype JOIN_UNIQUE_OUTER). What I don't
> understand is how it ca
On Wed, Feb 11, 2009 at 8:24 PM, Tom Lane wrote:
> [ forgot to respond to this earlier, sorry ]
Thanks for responding now.
> Robert Haas writes:
>> On a related note, I have some vague unease about planning A SEMI JOIN
>> B as A INNER JOIN (UNIQUE B), as make_one_rel currently attempts to
>> do
[ forgot to respond to this earlier, sorry ]
Robert Haas writes:
> On a related note, I have some vague unease about planning A SEMI JOIN
> B as A INNER JOIN (UNIQUE B), as make_one_rel currently attempts to
> do. For a merge join or nested loop, I don't see how this can ever be
> a win over tea
> I think the only fix for this that's practical in the 8.4 time frame is
> to give up trying to flatten EXISTS/NOT EXISTS that occur within the ON
> condition of an outer join, ie, revert to 8.3's level of intelligence
> about this case. It seems like a general purpose solution would involve
> so
"Kevin Grittner" writes:
> Tom Lane wrote:
>> If it referred to any variables of the left side of the upper join
>> (ie, "C" here) then we couldn't convert it to a separate join at
> all.
> The only thing that comes to mind for me that seems possibly helpful
> is that we have typically conside
>>> Tom Lane wrote:
> SELECT ... FROM
> "Case" "C"
> LEFT OUTER JOIN "CaseDispo" "CD"
> ON ("CD"."caseNo" = "C"."caseNo") AND ("CD"."countyNo" =
"C"."countyNo")
> AND (NOT (EXISTS (SELECT 1 FROM "CaseDispo" "CD2"
> WHERE ("CD2"."caseNo" = "CD"."caseNo")
>
I looked into the planning problems in HEAD discussed here:
http://archives.postgresql.org/pgsql-hackers/2009-02/msg00120.php
As I suspected, there are really two independent bugs there,
though both are in the new semi/antijoin planning code.
The first problem is the one already mentioned: cost_me
17 matches
Mail list logo
