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
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 |