From: | David Roussel <pgsql-performance(at)diroussel(dot)xsmail(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:43:12 |
Message-ID: | 43661F70.6060006@diroussel.xsmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Rodrigo Madera wrote:
> 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?
I have a system that does this. We do it by PK, the PK is bigint, and
always increases, the client remembers the last key seen as queries
based on that key...
select ... where events.event_id > ?::bigint order by events.event_id
limit 2000
it works, but when alot of data is added, it can become sensative to the
index statistics getting out of sync with the data. Best to insert,
then update the statistics, then read the data. For us these three
activities are independent, but it still seems to work.
I'd investigate the notify mechanism suggested by Otto if you can afford
to use a postgres specific mechanism like that.
David
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2005-10-31 13:47:29 | Re: Best way to check for new data. |
Previous Message | Qingqing Zhou | 2005-10-31 09:48:41 | Re: performance of implicit join vs. explicit conditions on inet queries? |