Re: count(*) and bad design was: Experiences with extensibility

From: Harald Fuchs <hf0217x(at)protecting(dot)net>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: count(*) and bad design was: Experiences with extensibility
Date: 2008-01-10 11:04:06
Message-ID: pufxx6hrh5.fsf@srv.protecting.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

In article <60ejcqy6j0(dot)fsf(at)dba2(dot)int(dot)libertyrms(dot)com>,
Chris Browne <cbbrowne(at)acm(dot)org> writes:

> There may be a further optimization to be had by doing a
> per-statement trigger that counts the number of INSERTs/DELETEs done,
> so that inserting 30 tuples (in the table being tracked) leads to
> adding a single tuple with count of 30 in the summary table.

This would be nice, but at least the 8.2.4 docs say

Statement-level triggers do not currently have any way to examine
the individual row(s) modified by the statement.

Is this restriction removed in a later version?

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Lars Heidieker 2008-01-10 11:05:59 Re: vacuum, dead rows, usual solutions didn't help
Previous Message Martijn van Oosterhout 2008-01-10 10:57:58 Re: count(*) and bad design was: Experiences with extensibility