Thread: Persistent objects within PG or the availability of non-logged tables or databases?
Persistent objects within PG or the availability of non-logged tables or databases?
From
Keaton Adams
Date:
Is there a way to manage a queue in memory within Postgres?
We have a scenario where we have a list of servers stored in a table. Multiple clients make a request for the next “group” of servers to process. Something within the database needs to keep track of the last server set that was passed back to a client so the entire server list is rotated through in a round-robin fashion. Is there a way for an object (variable/table/etc) to remain persistent in memory that is shared among multiple client sessions? If not, an alternative we thought of is to use a small table within the DB in conjunction with a function to keep track of the last set of data. The question we have, though, is the rate at which the table is updated (possibly many times per second) and the amount of WAL data that is generated by this operation.
Is there such as thing as a non-logged table or a non-logged database in PG?
I have looked through the docs and can’t find anything on this subject, so I thought someone on the list might know of a feature (current or upcoming) that might be helpful.
Thanks,
Keaton
Re: Persistent objects within PG or the availability of non-logged tables or databases?
From
"Joshua D. Drake"
Date:
On Tue, 8 Apr 2008 11:19:57 -0600 Keaton Adams <kadams@mxlogic.com> wrote: > there a way for an object (variable/table/etc) to remain persistent > in memory that is shared among multiple client sessions? If not, an > alternative we thought of is to use a small table within the DB in > conjunction with a function to keep track of the last set of data. > The question we have, though, is the rate at which the table is > updated (possibly many times per second) and the amount of WAL data > that is generated by this operation. You could use pg_memcache. > > Is there such as thing as a non-logged table or a non-logged database > in PG? No but if the updates taking place are on columns that are not indexed (and you are running 8.3) then HOT will kick in and the load is significantly reduced. E.g.; CREATE TABLE foo (id serial pk, bar text); UPDATE foo SET bar = 'baz'; Will not create a dead row and thus greatly reduces overall load and maintenance requirements. SIncerely, Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate