>>> Tom Lane <[EMAIL PROTECTED]> wrote:
> If you're still interested in testing CVS HEAD's handling of EXISTS,
> I've about finished what I wanted to do with it.
It's been hectic here, but I've managed to let some stuff run in the
background using an old test case from here:
http://archives.po
On Wed, Sep 3, 2008 at 9:17 AM, daveg <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 14, 2008 at 06:50:09PM +0100, Simon Riggs wrote:
> >
> > On Fri, 2008-08-08 at 16:23 -0400, Tom Lane wrote:
> >
> > > NOT IN is a lot trickier,
> > > condition: you must also assume that the comparison operator involved
On Thu, Aug 14, 2008 at 06:50:09PM +0100, Simon Riggs wrote:
>
> On Fri, 2008-08-08 at 16:23 -0400, Tom Lane wrote:
>
> > NOT IN is a lot trickier,
> > condition: you must also assume that the comparison operator involved
> > never yields NULL for non-null inputs. That might be okay for btree
>
>>> On Sun, Aug 17, 2008 at 4:29 PM, in message
<[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> If you're still interested in testing CVS HEAD's handling of EXISTS,
> I've about finished what I wanted to do with it.
Thanks. I'm very interested; unfortunately I can't get to it until
Hello
I did some fast test on pagila database.
8.4
postgres=# explain analyze select * from film f where exists (select
film_id from film_actor where f.film_id = film_id);
QUERY PLAN
---
If you're still interested in testing CVS HEAD's handling of EXISTS,
I've about finished what I wanted to do with it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/ma
On Fri, 2008-08-08 at 16:23 -0400, Tom Lane wrote:
> NOT IN is a lot trickier,
> for the same reason that typically trips up novices who try to use it:
> if any row of the subselect produces a NULL comparison result, then it
> is impossible for the NOT IN to result in TRUE, which means that it
>
On Aug 11, 2008, at 3:40 PM, Gregory Stark wrote:
"Decibel!" <[EMAIL PROTECTED]> writes:
On Aug 8, 2008, at 3:23 PM, Tom Lane wrote:
* has no set operations (UNION etc), grouping, set-returning
functions
in the SELECT list, LIMIT, or a few other funny cases
Couldn't union/union all be trea
Decibel! <[EMAIL PROTECTED]> writes:
> On Aug 8, 2008, at 3:23 PM, Tom Lane wrote:
>> * has no set operations (UNION etc), grouping, set-returning functions
>> in the SELECT list, LIMIT, or a few other funny cases
> Couldn't union/union all be treated as
> EXISTS(a)
> OR EXISTS(b)
Perhaps, but th
"Decibel!" <[EMAIL PROTECTED]> writes:
> On Aug 8, 2008, at 3:23 PM, Tom Lane wrote:
>> * has no set operations (UNION etc), grouping, set-returning functions
>> in the SELECT list, LIMIT, or a few other funny cases
>
>
> Couldn't union/union all be treated as
>
> EXISTS(a)
> OR EXISTS(b)
Kind of
Our Internet connectivity failed as this was being sent. It looks
like at least the list didn't get it, so here goes another try.
Apologies for any duplication.
-Kevin
>>> Tom Lane <[EMAIL PROTECTED]> wrote:
> I chewed on that for awhile. We can certainly optimize EXISTS
that's
> appear
On Aug 8, 2008, at 3:23 PM, Tom Lane wrote:
* has no set operations (UNION etc), grouping, set-returning functions
in the SELECT list, LIMIT, or a few other funny cases
Couldn't union/union all be treated as
EXISTS(a)
OR EXISTS(b)
...
Or am I missing some detail with NULLS?
Personally, I'd
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> I believe that the optimizable cases for EXISTS are those where the
>> EXISTS() is either at the top level of WHERE, or just underneath a
>> NOT,
> The rest of the plan makes sense to me, but this part seems na
>>> Tom Lane <[EMAIL PROTECTED]> wrote:
> I believe that the optimizable cases for EXISTS are those where the
> EXISTS() is either at the top level of WHERE, or just underneath a
NOT,
The rest of the plan makes sense to me, but this part seems narrow.
There's probably a good reason for that w
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
>>> I'm adding some NOT EXISTS examples to the thread for completeness
>>> of what someone might want to address while working on it. For two
>>> queries which can easily be shown (to a human viewer, anyway) to
>>> return identical results, I see perfor
>>> On Mon, Aug 4, 2008 at 6:48 PM, in message
<[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
>> I'm adding some NOT EXISTS examples to the thread for completeness
of
>> what someone might want to address while working on it. For two
>> qu
>>> On Mon, Aug 4, 2008 at 6:48 PM, in message
<[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
>> I'm adding some NOT EXISTS examples to the thread for completeness
of
>> what someone might want to address while working on it. For two
>> qu
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> I'm adding some NOT EXISTS examples to the thread for completeness of
> what someone might want to address while working on it. For two
> queries which can easily be shown (to a human viewer, anyway) to
> return identical results, I see performance di
>>> On Mon, Oct 22, 2007 at 1:30 PM, Simon Riggs wrote:
> On Mon, 2007-10-22 at 09:31 -0500, Kevin Grittner wrote:
>> I've requested this before without response, but I'm asking again
>> because it just caused me pain again: could we get a TODO added to
>> have the planner recognize equivalent IN
>>> On Mon, Oct 22, 2007 at 5:04 PM, in message
<[EMAIL PROTECTED]>, "Kevin Grittner"
> Oops. That is not logically equivalent. We want to delete WHERE NOT
> EXISTS; the logic of that suggestion is backwards.
>
> Disregard that last post, please.
Maybe that last post shouldn't be totally disr
2007/10/23, Kevin Grittner <[EMAIL PROTECTED]>:
> >>> On Mon, Oct 22, 2007 at 4:37 PM, in message
> <[EMAIL PROTECTED]>, "Kevin Grittner"
> <[EMAIL PROTECTED]> wrote:
>
> > One more logically equivalent, PostgreSQL-specific form which
> > costs out even better was suggested off-list:
>
> Oops. Th
>>> On Mon, Oct 22, 2007 at 4:37 PM, in message
<[EMAIL PROTECTED]>, "Kevin Grittner"
<[EMAIL PROTECTED]> wrote:
> One more logically equivalent, PostgreSQL-specific form which
> costs out even better was suggested off-list:
Oops. That is not logically equivalent. We want to delete WHERE NOT
>>> On Mon, Oct 22, 2007 at 1:30 PM, in message
<[EMAIL PROTECTED]>, Simon Riggs <[EMAIL PROTECTED]>
wrote:
> On Mon, 2007-10-22 at 09:31 -0500, Kevin Grittner wrote:
>> I've requested this before without response, but I'm asking again
>> because it just caused me pain again: could we get a TODO
On Mon, 2007-10-22 at 09:31 -0500, Kevin Grittner wrote:
> I've requested this before without response, but I'm asking again
> because it just caused me pain again: could we get a TODO added to
> have the planner recognize equivalent IN and EXISTS constructs and
> have them compete on cost estimate
24 matches
Mail list logo
