From: | James William Pye <lists(at)jwp(dot)name> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com> |
Cc: | Ivan Sergio Borgonovo <mail(at)webthatworks(dot)it>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: C function accepting/returning cstring vs. text |
Date: | 2010-01-27 21:13:37 |
Message-ID: | 200D6373-315D-440A-B28D-739D5FC5ABC6@jwp.name |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jan 27, 2010, at 1:00 PM, Joe Conway wrote:
> Implementing true value_per_call is still something on my TODO list, but
> obviously has not risen to a very high priority for me as it has now
> been an embarrassing long time since it was put there. But that said,
> materialize mode has proven extremely good at covering the most common
> use cases with acceptable performance.
Hrm. I think this has been noted before, but one of the problems with VPC is that there can be a fairly significant amount of overhead involved with context setup and teardown--especially with PLs. If you're streaming millions of rows, it's no longer a small matter.
I would think some extension to Tuplestore would be preferable. Where chunks of rows are placed into the Tuplestore on demand in order to minimize context setup/teardown overhead. That is, if the Tuplestore is empty and the user needs more rows, invoke the procedure again with the expectation that it will dump another chunk of rows into the container. Not a formal specification by any means, but I'm curious if anyone has considered that direction.
Or along the same lines, how about a valueS-per-call mode? =)
From | Date | Subject | |
---|---|---|---|
Next Message | Ivan Sergio Borgonovo | 2010-01-27 21:14:22 | Re: C function accepting/returning cstring vs. text |
Previous Message | Robert Haas | 2010-01-27 21:05:52 | CommitFest status summary 2010-01-27 |