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 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
never
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:
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
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 at
least
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:
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
does
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 treated
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 narrow.
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
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
appearing in
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 confused by
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 that would
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
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 which
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
queries which can
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
queries which can
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 and
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
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. That is not logically
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 disregarded --
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 estimates? I know it's not a trivial
improvement, but if it's on the
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 estimates?
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 added to
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
EXISTS;
25 matches
Mail list logo
