Re: Modify pg_stat_get_activity to build a tuplestore - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Modify pg_stat_get_activity to build a tuplestore
Date
Msg-id 20150508135848.GJ2523@alvh.no-ip.org
Whole thread Raw
In response to Modify pg_stat_get_activity to build a tuplestore  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Modify pg_stat_get_activity to build a tuplestore  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Stephen Frost wrote:

> As I mentioned on another thread, you're certainly right about that, and
> here's the first broken-out patch, which just changes
> pg_stat_get_activity to build and return a tuplestore in a single
> function call instead of using the old-style multiple-invokation call
> method.  Given the simplicity and the lack of any user-visible change,
> and that it's an independently useful change regardless of what happens
> with the other changes, I'm planning to move forward with this pretty
> quickly, barring concerns, of course.

Um.  Abhijit mentioned to me the idea of implementing function execution
code in fmgr that would allow for calling functions lazily (i.e. stop
calling it once enough rows have been returned).  One of the reasons not
to do that is that most functions use the materialize mode rather than
value-per-call, so the optimization is pointless because the whole
result is computed anyway.  If we change more functions to materialize,
we will make that sort of optimization even more distant.

What is the reason for this change anyway?

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Remove obsolete mention of src/tools/backend
Next
From: Bernd Helmle
Date:
Subject: Re: Disabling trust/ident authentication configure option