Re: [HACKERS] Hypothetical suggestions for planner, indexing improvement - Mailing list pgsql-performance

From Jim C. Nasby
Subject Re: [HACKERS] Hypothetical suggestions for planner, indexing improvement
Date
Msg-id 20030506080747.C66185@flake.decibel.org
Whole thread Raw
In response to Re: [HACKERS] Hypothetical suggestions for planner, indexing improvement  (Josh Berkus <josh@agliodbs.com>)
Responses Re: [HACKERS] Hypothetical suggestions for planner, indexing improvement
Re: [HACKERS] Hypothetical suggestions for planner, indexing
List pgsql-performance
On Mon, May 05, 2003 at 09:33:33PM -0700, Josh Berkus wrote:
> EXISTS is more flexible than IN; how can you do a 3-column corellation on an
> IN clause?

It would be nice to add support for multi-column IN..

WHERE (a, b, c) IN (SELECT a, b, c ...)

BTW, does postgresql handle IN and EXISTS differently? Theoretically if
the optimizer was good enough you could transform one to the other and
not worry about it. Whenever possible, I try and use IN when the
subselect will return a very small number of rows, since IN might be
faster than EXISTS in that case, though it seems most optimizers tend to
fall apart when they see ORs, and a lot of databases transform IN to a
OR b OR c.
--
Jim C. Nasby (aka Decibel!)                    jim@nasby.net
Member: Triangle Fraternity, Sports Car Club of America
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"


pgsql-performance by date:

Previous
From: Richard Huxton
Date:
Subject: Re: Select on timestamp-day slower than timestamp alone
Next
From: "Jim C. Nasby"
Date:
Subject: Re: [HACKERS] Hypothetical suggestions for planner, indexing improvement