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)
