Thread: Large journal as psql table. Good idea? Triggering.

Dear Postgres folks;

I'm considering using a postgres table for something that could be done
with a flat file.  Is this a good idea?

I have events on a machine "A", which need to be sent by an SMS/Cell
Phone modem that's on a totally different machine "B".  Potentially this
is a job for a flat file FIFO.

But I'm thinking that maybe it's a job for a database table.  Each new
row would be written with a status (10="new").  And that the modem
process would poll for new rows.  Problem is there will be lots of rows,
but only a trivial few will be "new".  The huge index file and the
polling seem like a drag on the database, unless there is a way to optimize.

On the good side, this scheme handles building the FIFO and the IPC
(interprocess communication).  Is is a good approach, using postgres as
a glorified FIFO?  Should the DB on machine "A" or "B"? Is there a way
to trigger or lower the polling overhead (in this application the delay
is user visible).  The volume is low (a few messages a minute tops).
                     Bryce

> But I'm thinking that maybe it's a job for a database table.  Each
> new
> row would be written with a status (10="new").  And that the modem
> process would poll for new rows.  Problem is there will be lots of
> rows,
> but only a trivial few will be "new".  The huge index file and the
> polling seem like a drag on the database, unless there is a way to
> optimize.

create index <name> on <table>( <id> ) where status = 'new';

this index will be very fast.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com