a patch for row-at-a-time execution for table functions - Mailing list pgsql-hackers

From David Gudeman
Subject a patch for row-at-a-time execution for table functions
Date
Msg-id CAE4YsyjoMvbbEZ3oYe6DkVsM9mW4EMtOtXL9_pMVSOMLs8o-=g@mail.gmail.com
Whole thread Raw
Responses Re: a patch for row-at-a-time execution for table functions
List pgsql-hackers
The primary change we made to Postgres in order to support our own
version of foreign data wrappers was a row-at-a-time execution for
table functions. In standard Postgres, when you execute a table
function, it gathers all of the rows at once and stuffs them into a
buffer in order to support cursors, even if it is just a vanilla
forward scan. We modified the code so that when you do vanilla forward
scans it executes the function one row at a time. This wasn't a big
change since the support for executing functions that way was always
in there but it was bypassed in the plan execution code. Probably
someone always intended to do this, but never got around to it.

We also encountered what I think is a bug in the way that the cleanup
callback functions are called at the end of a table function. I'm not
sure I remember the details correctly, but I believe it was freeing
the memory region used for the private state before calling the
cleanup function. If that was the bug though, why didn't I just use
malloc for the private state? I'll have to review my notes on that
one...

Anyway, my company has agreed to let me post a patch for these
changes. Before I go to the work of getting the patches ready, I'd
like to take the temperature of the commiters and find out if there is
any likelihood of getting these patches accepted.

Anyone?



pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Enabling Checksums
Next
From: Joe Conway
Date:
Subject: Re: a patch for row-at-a-time execution for table functions