Skip site navigation (1) Skip section navigation (2)

Re: C function accepting/returning cstring vs. text

From: Ivan Sergio Borgonovo <mail(at)webthatworks(dot)it>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: C function accepting/returning cstring vs. text
Date: 2010-01-27 21:14:22
Message-ID: 20100127221422.2bcb4ed6@dawn.webthatworks.it (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, 27 Jan 2010 22:06:43 +0200
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:

> Ivan Sergio Borgonovo wrote:
> > But then... why do we have all that logic to save the function
> > context if anyway it is more convenient to process everything in
> > one run?
> > It's a pain to save the context just to save a pointer inside a
> > structure, it would be more convenient to just process all the
> > structure and return it as a Tuplestore in one pass.
> 
> When the set-returning-function feature was written originally,
> years ago, the tuple at a time mode did really work tuple at a
> time. But it had issues and was axed out of the patch before it
> was committed, to keep it simple. The idea was to revisit it at
> some point, but it hasn't bothered anyone enough to fix it. It's
> basically "not implemented yet".

Summing it up:
1) tuple at a time theoretically should be better and "future proof"
   once someone write the missing code but the code is still not
   there
2) practically there is no substantial extra cost in returning tuple
   at a time

Is 2) really true?
It seems that materialized mode is much simpler. It requires a lot
less code and it doesn't force you to save local variables and then
restore them every time.

So does it still make sense to get an idea about when the returned
data set and complexity of computation really fit value_per_call or
materialized mode?

What could happen between function calls in value_per_call?
Would still value_per_call offer a chance to postgresql/OS to better
allocate CPU cycles/memory?

thanks

-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it


In response to

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2010-01-27 21:23:12
Subject: Re: [COMMITTERS] pgsql: Remove tabs in SGML.
Previous:From: James William PyeDate: 2010-01-27 21:13:37
Subject: Re: C function accepting/returning cstring vs. text

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group