Re: C function accepting/returning cstring vs. text

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? =)

In response to

Browse pgsql-hackers by date

  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