Re: Suggestion for optimization

From: Jeff Davis <list-pgsql-hackers(at)dynworks(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Suggestion for optimization
Date: 2002-04-05 21:09:08
Message-ID: 200204052110.NAA10222@smtp.ucsd.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> >> It would be nice if total table cardinality could be maintained live.
> >
> > How would this work with MVCC?
>
> It wouldn't. That's why it's not there. Under MVCC, table cardinality
> is in the eye of the beholder...

That makes me curious how oracle implements it. I was under the impression
that oracle managed to get the two together (MVCC and cardinality).

Also, can't triggers basically solve the problem from a functionaility
standpoint? I mean, it would be slow for inserts, but I wonder if similar
principles could be applied without the full overhead of triggers?

What I had in mind was to create a stats table (I guess much like the one
that already exists, or a separate attribute of the existing one) and all of
the tables in there, with a rowcount. Once a row is inserted, the trigger
runs and updates the count (or decrements for delete), making the new count
visible to the current transaction. Then when the transaction commits, it's
visible everywhere at the same time as the count.

Is there anything wrong with that setup, other than the obvious performance
hit?

By the way, since this discussion has happened before, I actually read a
similar idea in a previous email (if I remember correctly), but I didn't see
much talk about it.

Regards,
Jeff

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2002-04-05 21:53:47 Re: PQescapeBytea is not multibyte aware
Previous Message Dann Corbit 2002-04-05 21:07:51 Re: Suggestion for optimization