: Re: [PERFORM] optimizing queries using IN and EXISTS
Nick Hofstede nick.hofst...@inventivegroup.com writes:
I'm surprised at the difference in speed/execution plan between two
logically equivalent queries, one using IN, the other using EXISTS.
(At least I think they are logically equivalent
Hi,
I'm surprised at the difference in speed/execution plan between two logically
equivalent queries, one using IN, the other using EXISTS. (At least I think
they are logically equivalent)
I've created a small setup that illustrates what I mean.
Consider the following tables:
CREATE TABLE
On 18 July 2012 17:10, Nick Hofstede nick.hofst...@inventivegroup.com wrote:
Hi,
I'm surprised at the difference in speed/execution plan between two logically
equivalent queries, one using IN, the other using EXISTS. (At least I think
they are logically equivalent)
They are not logically
: woensdag 18 juli 2012 20:40
Aan: Nick Hofstede
CC: pgsql-performance@postgresql.org
Onderwerp: Re: [PERFORM] optimizing queries using IN and EXISTS
On 18 July 2012 17:10, Nick Hofstede nick.hofst...@inventivegroup.com wrote:
Hi,
I'm surprised at the difference in speed/execution plan between two
Nick Hofstede nick.hofst...@inventivegroup.com writes:
I'm surprised at the difference in speed/execution plan between two logically
equivalent queries, one using IN, the other using EXISTS. (At least I think
they are logically equivalent)
SELECT *
FROM foo
WHERE 'text6' IN (SELECT
Hello,
I'm developing some routines that will use temporary tables and need
advice on how to not lose performance.
I will insert data in a temporary table and use this data to generate
new sets that will update or add to the same temporary table.
I have some questions that I'm concerned
On Jan 22, 2008 1:32 PM, Luiz K. Matsumura [EMAIL PROTECTED] wrote:
Hello,
I'm developing some routines that will use temporary tables and need
advice on how to not lose performance.
I will insert data in a temporary table and use this data to generate
new sets that will update or add to
On Tue, 2006-08-08 at 16:42 -0400, Tom Lane wrote:
Patrice Beliveau [EMAIL PROTECTED] writes:
SELECT * FROM TABLE
WHERE TABLE.COLUMN1=something
AND TABLE.COLUMN2=somethingelse
AND function(TABLE.COLUMN3,TABLE.COLUMN4) 0;
I find out that the function process every row even if the row
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
If subquerys are not working I think you should try to create a view
with the subquery.
Maybe it will work.
Patrice Beliveau wrote:
Tom Lane wrote:
Patrice Beliveau [EMAIL PROTECTED] writes:
SELECT * FROM TABLE
WHERE TABLE.COLUMN1=something
Patrice Beliveau [EMAIL PROTECTED] writes:
Tom Lane wrote:
PG 8.1 will not reorder WHERE clauses for a single table unless it has
some specific reason to do so (and AFAICT no version back to 7.0 or so
has done so either...) So there's something you are not telling us that
is relevant.
here
Hi,
I have a query that use a function and some column test to select row.
It's in the form of:
SELECT * FROM TABLE
WHERE TABLE.COLUMN1=something
AND TABLE.COLUMN2=somethingelse
AND function(TABLE.COLUMN3,TABLE.COLUMN4) 0;
The result of the function does NOT depend only from the
On Tue, 2006-08-08 at 12:49, Patrice Beliveau wrote:
Hi,
I have a query that use a function and some column test to select row.
It's in the form of:
SELECT * FROM TABLE
WHERE TABLE.COLUMN1=something
AND TABLE.COLUMN2=somethingelse
AND
Scott Marlowe wrote:
On Tue, 2006-08-08 at 12:49, Patrice Beliveau wrote:
Hi,
I have a query that use a function and some column test to select row.
It's in the form of:
SELECT * FROM TABLE
WHERE TABLE.COLUMN1=something
AND TABLE.COLUMN2=somethingelse
AND
Patrice Beliveau [EMAIL PROTECTED] writes:
SELECT * FROM TABLE
WHERE TABLE.COLUMN1=something
AND TABLE.COLUMN2=somethingelse
AND function(TABLE.COLUMN3,TABLE.COLUMN4) 0;
I find out that the function process every row even if the row should be
rejected as per the first or the second
14 matches
Mail list logo
