From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com> |
Cc: | Eliot Gable <egable+pgsql-performance(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Replacing Cursors with Temporary Tables |
Date: | 2010-04-24 15:20:12 |
Message-ID: | y2kb42b73151004240820u5a0082dt2201eef3c4dafa87@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
2010/4/24 Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com>:
>
>
> On Sat, Apr 24, 2010 at 2:23 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>>
>> Well, you missed the most important part: not using cursors at all.
>> Instead of declaring a cursor and looping it to build the array, build
>> it with array(). That's what I've been saying: arrays can completely
>> displace both temp tables _and_ cursors when passing small sets around
>> functions.
>>
> with huge emphasis on the word small.
The rule of thumb I use is 10000 narrow records (scalars, or very
small composites) or 1000 wide/complex records. I routinely pass
extremely complex (3-4 levels nesting) nested composite arrays to the
client for processing -- it is extremely efficient and clean. This of
course is going to depend on hardware and other factors.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Коротков Александр | 2010-04-25 18:22:29 | Planner issue on sorting joining of two tables with limit |
Previous Message | Grzegorz Jaśkiewicz | 2010-04-24 14:38:02 | Re: Replacing Cursors with Temporary Tables |