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

pgsql: Reduce the memory footprint of large pending-trigger-event lists,

From: tgl(at)postgresql(dot)org (Tom Lane)
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Reduce the memory footprint of large pending-trigger-event lists,
Date: 2008-10-24 23:42:35
Message-ID: 20081024234236.0053C7545A4@cvs.postgresql.org (view raw or flat)
Thread:
Lists: pgsql-committers
Log Message:
-----------
Reduce the memory footprint of large pending-trigger-event lists, as per my
recent proposal.  In typical cases, we now need 12 bytes per insert or delete
event and 16 bytes per update event; previously we needed 40 bytes per
event on 32-bit hardware and 80 bytes per event on 64-bit hardware.  Even
in the worst case usage pattern with a large number of distinct triggers being
fired in one query, usage is at most 32 bytes per event.  It seems to be a
bit faster than the old code as well, due to reduction of palloc overhead.

This commit doesn't address the TODO item of allowing the event list to spill
to disk; rather it's trying to stave off the need for that.  However, it
probably makes that task a bit easier by reducing the data structure's
dependency on pointers.  It would now be practical to dump an event list to
disk by "chunks" instead of individual events.

Modified Files:
--------------
    pgsql/src/backend/commands:
        trigger.c (r1.237 -> r1.238)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/trigger.c?r1=1.237&r2=1.238)
    pgsql/src/include/commands:
        trigger.h (r1.68 -> r1.69)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/commands/trigger.h?r1=1.68&r2=1.69)

pgsql-committers by date

Next:From: Tom LaneDate: 2008-10-25 03:32:44
Subject: pgsql: Fix an old bug in after-trigger handling: AfterTriggerEndQuery
Previous:From: Magnus HaganderDate: 2008-10-24 12:48:31
Subject: pgsql: Replace now unnecessary goto statements by using return directly.

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