From: dracula007@atlas.cz
To: pgsql-sql@postgresql.org
Subject: Re: **SPAM** Faster count(*)?
Date: Wed, 10 Aug 2005 01:29:58 +0200
Message-ID: <196456155.20050810012958@karneval.cz> (raw)
In-Reply-To: <000101c59d33$36a4a560$9b00015a@osl.com>
References: <000101c59d33$36a4a560$9b00015a@osl.com>
I believe running count(*) means fulltable scan, and there's no way
to do it without it. But what about some "intermediate" table, with
the necessary counts?
That means to create a table with values (counts) you need, and on
every insert/delete/update increment or decrement the appropriate
values. This way you won't need the count(*) query anymore, and the
performance should be much better.
t.v.
> Salve.
> I understand from various web searches and so on that PostgreSQL's MVCC
> mechanism makes it very hard to use indices or table metadata to optimise
> count(*). Is there a better way to guess the "approximate size" of a table?
> I'm trying to write a trigger that fires on insert and performs some
> maintenance (collapsing overlapping boxes into a single large box,
> specifically) as the table grows. My initial attempt involved count(*) and,
> as the number of pages in the table grew, that trigger bogged down the
> database.
> Any thoughts?
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: dracula007@atlas.cz
Subject: Re: **SPAM** Faster count(*)?
In-Reply-To: <196456155.20050810012958@karneval.cz>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox