Re: plan difference between set-returning function with ROWS within IN() and a plain join

From: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
To: "Frank van Vugt" <ftm(dot)van(dot)vugt(at)foxi(dot)nl>
Cc: pgsql-performance(at)postgresql(dot)org, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: plan difference between set-returning function with ROWS within IN() and a plain join
Date: 2008-05-10 11:42:28
Message-ID: b42b73150805100442n103701c4ud105cddac6f391e0@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, May 6, 2008 at 11:27 AM, Frank van Vugt <ftm(dot)van(dot)vugt(at)foxi(dot)nl> wrote:
>> > db=# explain analyse
>> > select sum(base_total_val)
>> > from sales_invoice
>> > where id in (select id from si_credit_tree(80500007));
>>
>> Did you check whether this query even gives the right answer?
>
> You knew the right answer to that already ;)
>
>> I think you forgot the alias foo(id) in the subselect and it's
>> actually reducing to "where id in (id)", ie, TRUE.
>
> Tricky, but completely obvious once pointed out, that's _exactly_ what was
> happening.

This is one of the reasons why, for a table named 'foo', I name the
columns 'foo_id', not 'id'. Also, if you prefix the id column with
the table name, you can usually use JOIN USING which is a little bit
tighter and easier than JOIN ON.

merlin

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Rauan Maemirov 2008-05-10 17:31:22 Re: Query Optimization with Kruskal’s Algorithm
Previous Message Tom Lane 2008-05-09 14:12:46 Re: "append" takes a lot of time in a query