From: | "Shridhar Daithankar" <shridhar_daithankar(at)persistent(dot)co(dot)in> |
---|---|
To: | pg_general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Postgresql "FIFO" Tables, How-To ? |
Date: | 2003-07-16 16:50:10 |
Message-ID: | 3F15CF9A.27760.205495A@localhost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 16 Jul 2003 at 10:13, scott.marlowe wrote:
> On Wed, 16 Jul 2003, Shridhar Daithankar wrote:
> > It would be a bad idea to update the control table itself. You need to release
> > the lock with transaction commit.( I hope it gets released with the commit) If
> > you update control table, you would generate a dead row for every insertion in
> > main table which could be a major performance penalty for sizes you are talking
> > about.
> >
> > Frankly I would like to know fist why do you want to do this. Unless there are
> > good enough practical reasons, I would not recommend this approach at all. Can
> > you tell us why do you want to do this?
>
> If he only needs an approximate number of rows (i.e. having max +/- 100
> rows is ok...) then maybe just use a sequence and delete any rows that
> are current_max_seq - max_records???
Surely there are more than one way to do it depending upon how much strict OP
wants to be. This seems to be a much better solution along with periodic vacuum
analyze if required.
Bye
Shridhar
--
"On a normal ascii line, the only safe condition to detect is a 'BREAK'-
everything else having been assigned functions by Gnu EMACS."(By Tarl
Neustaedter)
From | Date | Subject | |
---|---|---|---|
Next Message | Bruno Wolff III | 2003-07-16 16:50:51 | Re: Postgresql "FIFO" Tables, How-To ? |
Previous Message | Andrew Sullivan | 2003-07-16 16:47:58 | Re: ODBC query problem |