From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | John DeSoi <desoi(at)pgedit(dot)com> |
Cc: | Sam Mason <sam(at)samason(dot)me(dot)uk>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: join from array or cursor |
Date: | 2009-08-23 02:36:09 |
Message-ID: | 407d949e0908221936u232b48e9pd68fe89a666ef0d9@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sun, Aug 23, 2009 at 1:30 AM, John DeSoi<desoi(at)pgedit(dot)com> wrote:
> While it avoids the sort of my method, it appears to be almost 5 times
> slower (about 4000 keys in the cursor, Postgres 8.4.0):
>
>
> Function Scan on cursor_pk arr (cost=0.00..116011.72 rows=1000 width=4)
> (actual time=13.561..249.916 rows=4308 loops=1)
> SubPlan 1
> SubPlan 2
> SubPlan 3
> ...
Ugh, I guess using a subquery didn't work around the problem of the
(r).* getting expanded into multiple columns. This is starting to be a
more annoying limitation than I realized.
This also means when we do things like
select (x).* from (select bt_page_items(...))
or
select (h).* from (select heap_page_items(...))
It's actually calling bt_page_items() repeatedly, once for every
column in the output record? Bleagh.
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Ross | 2009-08-23 03:03:26 | Re: Multiple table entries? |
Previous Message | Greg Stark | 2009-08-23 02:27:31 | Re: Multiple table entries? |