: Re: [PERFORM] optimizing queries using IN and EXISTS
Nick Hofstede 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)
> SELE
Nick Hofstede 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 value
>FRO
Verzonden: 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 wrote:
> Hi,
>
> I'm surprised at the difference in speed/execution plan between two logical
On 18 July 2012 17:10, Nick Hofstede 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 equivalent.
http://www.postg
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 foo
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 a
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 abo
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 ever
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 releva
I've create a view, same query plan (some number vary a bit, but nothing
significant) and same result, closed sales_order are processed
Ruben Rubio wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
If subquerys are not working I think you should try to create a view
with the subquery.
Mayb
-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.COL
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 should be
rejected as per
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 t
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 function(TABLE.COL
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 function(TABLE.COLUMN3,TABLE
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
16 matches
Mail list logo
