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

Re: Best way to check for new data.

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Rodrigo Madera" <rodrigo(dot)madera(at)gmail(dot)com>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Best way to check for new data.
Date: 2005-10-31 13:47:29
Message-ID: 6EE64EF3AB31D5448D0007DD34EEB3417DD719@Herge.rcsinc.local (view raw or flat)
Thread:
Lists: pgsql-performance
There are a few ways to do this...thinking about it a bit, I would add a timestamp column to your log table (indexed) and keep a control table which keeps track of the last log print sweep operation.

The print operation would just do 
select * from log where logtime > (select lastlogtime());

The idea here is not to have to keep track of anything on the log table like a flag indicating print status, which will cause some bloat issues.  All you have to do is reindex once in a while.

lastlogtime() is a function which returns the last log time sweep from the control table.  we use a function declared immutable to force planner to treat as a constant (others might tell you to do different here).

Merlin

________________________________________
From: pgsql-performance-owner(at)postgresql(dot)org [mailto:pgsql-performance-owner(at)postgresql(dot)org] On Behalf Of Rodrigo Madera
Sent: Friday, October 28, 2005 5:39 PM
To: pgsql-performance(at)postgresql(dot)org
Subject: [PERFORM] Best way to check for new data.

I have a table that holds entries as in a ficticious table Log(id integer, msg text).
 
Lets say then that I have the program log_tail that has as it´s sole purpose to print newly added data elements.
 
What is the best solution in terms of performace?
 
Thank you for your time,
Rodrigo
 

pgsql-performance by date

Next:From: Tom LaneDate: 2005-10-31 14:24:10
Subject: Re: performance of implicit join vs. explicit conditions on inet queries?
Previous:From: David RousselDate: 2005-10-31 13:43:12
Subject: Re: Best way to check for new data.

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