Erik Jones wrote:
These are all client databases at the web hosting company I work at.
I can't go putting triggers on all of their tables. I think I'll
just
start taking snapshots of pertinent data from pg_stat_activity and
after I've been collecting data for a while run a repor
Erik Jones writes:
> These are all client databases at the web hosting company I work at.
> I can't go putting triggers on all of their tables. I think I'll just
> start taking snapshots of pertinent data from pg_stat_activity and
> after I've been collecting data for a while run a report
On Mar 23, 2009, at 5:00 PM, Craig Ringer wrote:
Erik Jones wrote:
Am I missing something obvious here? If not, has anyone come up
with a reliable way to do this?
Triggers on all your tables that append to a logging table?
Have the client do it?
Note that you do *NOT* want to have trigg
Erik Jones wrote:
Am I missing something obvious here? If not, has anyone come up with a
reliable way to do this?
Triggers on all your tables that append to a logging table?
Have the client do it?
Note that you do *NOT* want to have triggers that attempt to UPDATE a
table to record the
Karsten Hilbert <[EMAIL PROTECTED]> writes:
> However, given your above description why does it not
> suffice to regenerate the report whenever the report
> generator connects ? If you want to do so only when the
> table has actually changed you might add a last_modified
> timestamp column with a
On Sat, Feb 11, 2006 at 09:26:57PM +0100, Johan Vromans wrote:
> Doug McNaught <[EMAIL PROTECTED]> writes:
> > Yeah, LISTEN/NOTIFY is definitely a lighter-weight solution--I didn't
> > think of that before.
>
> LISTEN/NOTIFY looks like a synchronisation mechanism. You can notify a
> subscriber th
Johan Vromans <[EMAIL PROTECTED]> writes:
> Doug McNaught <[EMAIL PROTECTED]> writes:
>> Yeah, LISTEN/NOTIFY is definitely a lighter-weight solution--I didn't
>> think of that before.
>
> LISTEN/NOTIFY looks like a synchronisation mechanism. You can notify a
> subscriber that something happened. B
Doug McNaught <[EMAIL PROTECTED]> writes:
> Yeah, LISTEN/NOTIFY is definitely a lighter-weight solution--I didn't
> think of that before.
LISTEN/NOTIFY looks like a synchronisation mechanism. You can notify a
subscriber that something happened. But in my case, the report
generating program runs on
Philippe Ferreira <[EMAIL PROTECTED]> writes:
>>Yeah, LISTEN/NOTIFY is definitely a lighter-weight solution--I didn't
>>think of that before.
>>
>>
> Hi,
>
> I'm interested too in using this method !
>
> Can anyone give a simple example of how to use/implement it ?
> Or good links to clear/quick d
Yeah, LISTEN/NOTIFY is definitely a lighter-weight solution--I didn't
think of that before.
Hi,
I'm interested too in using this method !
Can anyone give a simple example of how to use/implement it ?
Or good links to clear/quick documentation about these functions ?
Thank you,
Philippe Fe
Johan Vromans <[EMAIL PROTECTED]> writes:
> Doug McNaught <[EMAIL PROTECTED]> writes:
>
>> I would put an AFTER trigger on all the tables concerned that
>> inserts a row into an audit table. [...] Audit tables are useful for
>> other things too, if you can afford them.
>
> I think auditing is much
Doug McNaught <[EMAIL PROTECTED]> writes:
> I would put an AFTER trigger on all the tables concerned that
> inserts a row into an audit table. [...] Audit tables are useful for
> other things too, if you can afford them.
I think auditing is much too heavy for something simple as finding the
last
Use LISTEN/NOTIFY and a trigger.
Karsten
--
DSL-Aktion wegen großer Nachfrage bis 28.2.2006 verlängert:
GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl
---(end of broadcast)---
TIP 5: don't forget to increase your free space map se
Johan Vromans <[EMAIL PROTECTED]> writes:
> Greetings,
>
> For a big application, I want to generate reports from the database and
> keep these on-line as long as they reflect the actual contents of the
> database. I only want to regenerate the reports when needed, i.e.,
> when the database conten
14 matches
Mail list logo