Thread: pgsql: Perform less setup work for AFTER triggers at transaction start.
Perform less setup work for AFTER triggers at transaction start. Testing reveals that the memory allocation we do at transaction start has small but measurable overhead on simple transactions. To cut down on that overhead, defer some of that work to the point when AFTER triggers are first used, thus avoiding it altogether if they never are. Patch by me. Review by Andres Freund. Branch ------ master Details ------- http://git.postgresql.org/pg/commitdiff/2781b4bea7db357be59f9a5fd73ca1eb12ff5a79 Modified Files -------------- src/backend/commands/trigger.c | 428 ++++++++++++++++++++++------------------ 1 file changed, 232 insertions(+), 196 deletions(-)
Robert Haas <rhaas@postgresql.org> writes:
> Perform less setup work for AFTER triggers at transaction start.
Perhaps I'm confused, but doesn't AfterTriggerEnlargeQueryState()
need to ensure there are at least query_depth + 1 entries in the
arrays? Not just query_depth?
regards, tom lane
On Thu, Oct 23, 2014 at 1:57 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <rhaas@postgresql.org> writes: >> Perform less setup work for AFTER triggers at transaction start. > > Perhaps I'm confused, but doesn't AfterTriggerEnlargeQueryState() > need to ensure there are at least query_depth + 1 entries in the > arrays? Not just query_depth? Hmm, I think you're right. Like this? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Attachment
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Oct 23, 2014 at 1:57 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Perhaps I'm confused, but doesn't AfterTriggerEnlargeQueryState()
>> need to ensure there are at least query_depth + 1 entries in the
>> arrays? Not just query_depth?
> Hmm, I think you're right. Like this?
Yeah, that's what I meant.
regards, tom lane