| From: | Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org> |
|---|---|
| To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | Christopher Browne <cbbrowne(at)acm(dot)org>, <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Seqscan in MAX(index_column) |
| Date: | 2003-09-05 05:18:43 |
| Message-ID: | Pine.LNX.4.44.0309050712470.14280-100000@zigo.dhs.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 5 Sep 2003, Bruce Momjian wrote:
> > When I was curious as to how COUNT might be maintained, I was pretty
> > sure that this wouldn't be the preferred method...
>
> See my later idea of the trigger doing +/-1 rather than locking the
> value during the transaction.
>
> If we don't do it this way, I can't think of another way that would
> honor MVCC visibility.
A general query cache is something that is fairly clean and which might
help both with count(*) and other queries.
Many databases has a lot of tables that are more or less stable where this
would work fine. From what I have heard mysql has something like this and
it works well. For tables that change a lot the the cached queries will
almost always be invalid so one might want to let the user decide which
tables should never be cached.
It could at least be an interesting experiment.
--
/Dennis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christopher Kings-Lynne | 2003-09-05 06:04:35 | Re: Seqscan in MAX(index_column) |
| Previous Message | Bruce Momjian | 2003-09-05 04:28:25 | Re: Seqscan in MAX(index_column) |