"John Smith" <[EMAIL PROTECTED]> writes:
> Sorry for the long delay in following up on this suggestion. The
> change Tom suggested fixed the performance problems I was seeing, but
> I never ran the full regression suite on the modified code, as
> everything in my performance tests seemed to indicat
Sorry for the long delay in following up on this suggestion. The
change Tom suggested fixed the performance problems I was seeing, but
I never ran the full regression suite on the modified code, as
everything in my performance tests seemed to indicate the bug was
fixed (i.e, no errors even with --c
OK, added to TODO:
* Reduce memory usage of aggregates in set returning functions
http://archives.postgresql.org/pgsql-performance/2008-01/msg00031.php
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >
Bruce Momjian <[EMAIL PROTECTED]> writes:
> This this a bug or TODO item?
TODO, I think. I wouldn't want to risk pushing a change in this into
back branches.
regards, tom lane
>> I'm not sure why it's like this. Some digging in the CVS history shows
>> that indeed the c
This this a bug or TODO item?
---
Tom Lane wrote:
> "John Smith" <[EMAIL PROTECTED]> writes:
> >> It's pipelined either way. But int8 is a pass-by-reference data type,
> >> and it sounds like we have a memory leak for this
"John Smith" <[EMAIL PROTECTED]> writes:
>> It's pipelined either way. But int8 is a pass-by-reference data type,
>> and it sounds like we have a memory leak for this case.
> Thanks for your reply. How easy is it to fix this? Which portion of
> the code should we look to change?
I was just looki
> > Interestingly though, when the range in the generate_series() was
> > small enough to fit in 4 bytes of memory (e.g.
> > generate_series(1,10) ), the above query completed consuming
> > only negligible amount of memory. So, it looked like the aggregate
> > computation was being pipeline
"John Smith" <[EMAIL PROTECTED]> writes:
> Consider the following query:
> postgres=# select count(*) from
> generate_series(1,10);
> A vmstat while this query was running seems to suggest that the
> generate_series() was being materialized to disk first and then the
> cou
My set-up:
Postgres 8.2.5 on AMD x86_64 compiled with GCC 3.4.4 on Gentoo Linux 2.6.17
4 GB of RAM,
shared_buffers = 1000
work_mem = 1024
This is regarding performance of set-returning functions in queries. I
use generate_series() in the following as an example. The true
motivation is a need fo
