On 3/23/07, Kevin Grittner <[EMAIL PROTECTED]> wrote:
[...]
That's the good news. The bad news is that I operate under a management
portability dictate which doesn't currently allow that syntax, since not all of
the products they want to
It doesn't really touch the substance, but I am curiou
On Fri, Mar 23, 2007 at 05:30:27PM -0500, Kevin Grittner wrote:
> I don't understand -- TRUE OR UNKNOWN evaluates to TRUE, so why would
> the IN need to continue? I'm not quite following the rest; could you
> elaborate or give an example? (Sorry if I'm lagging behind the rest
> of the class here.
>>> On Fri, Mar 23, 2007 at 6:04 PM, in message
<[EMAIL PROTECTED]>, "Peter Kovacs"
<[EMAIL PROTECTED]> wrote:
> On 3/23/07, Kevin Grittner <[EMAIL PROTECTED]> wrote:
> [...]
>> That's the good news. The bad news is that I operate under a management
> portability dictate which doesn't currently
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> If you want that, try rewriting the EXISTS to an IN:
>>
>> AND ("H"."tranNo", "H"."countyNo") IN
>> (
>> SELECT "D"."tranNo", "D"."countyNo" FROM "TranDetail" "D"
>> WHERE "D"."caseNo" LIKE '2006TR%'
>> )
> Tha
>>> On Fri, Mar 23, 2007 at 5:26 PM, in message
<[EMAIL PROTECTED]>, "Kevin Grittner"
<[EMAIL PROTECTED]> wrote:
> I tried something which seems
> equivalent, but it is running for a very long time. I'll show it with just
> the explain while I wait to see how long the explain analyze takes.
I don't understand -- TRUE OR UNKNOWN evaluates to TRUE, so why would the IN
need to continue? I'm not quite following the rest; could you elaborate or
give an example? (Sorry if I'm lagging behind the rest of the class here.)
-Kevin
>>> Martijn van Oosterhout 03/23/07 5:26 PM >>>
On Fr
On Fri, Mar 23, 2007 at 05:49:42PM -0400, Tom Lane wrote:
> We don't currently try to flatten EXISTS into a unique/join plan as we
> do for IN. I seem to recall not doing so when I rewrote IN planning
> because I didn't think it would be exactly semantically equivalent,
> but that was awhile ago.
>>> On Fri, Mar 23, 2007 at 4:49 PM, in message <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
>> explain analyze
>> SELECT "A"."adjustmentNo", "A"."tranNo", "A"."countyNo", "H"."date",
> "H"."userId", "H"."time"
>> FROM "Adjustment" "
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> explain analyze
> SELECT "A"."adjustmentNo", "A"."tranNo", "A"."countyNo", "H"."date",
> "H"."userId", "H"."time"
> FROM "Adjustment" "A"
> JOIN "TranHeader" "H" ON ("H"."tranId" = "A"."adjustmentNo" AND
> "H"."countyNo" = "A"."countyNo" AND "H".
I'm posting this to performance in case our workaround may be of benefit to
someone with a similar issue. I'm posting to hackers because I hope we can
improve our planner in this area so that a workaround is not necessary. (It
might make sense to reply to one group or the other, depending on r
10 matches
Mail list logo
