Re: VACUUM and ANALYZE Follow-Up

From: Pierre-Frédéric Caillaud <lists(at)boutiquenumerique(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org
Subject: Re: VACUUM and ANALYZE Follow-Up
Date: 2004-11-30 16:02:19
Message-ID: opsiab551scq72hf@musicbox
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> Hasn't anybody read the other threads I posted links to?
> (That's a rhetorical question, because the answer clearly is "no" :-()

You mean this one :

http://archives.postgresql.org/pgsql-hackers/2004-11/msg00985.php

In which you write :

rel->pages = RelationGetNumberOfBlocks(relation);
if (relation->rd_rel->relpages > 0)
density = relation->rd_rel->reltuples / relation->rd_rel->relpages;
else if (relation->rd_rel->reltuples > 0) /* already a density */
density = relation->rd_rel->reltuples;
else
density = some_default_estimate;
rel->tuples = round(rel->pages * density);

> A variant of this is to set reltuples = density, relpages = 1 instead
> of 0, which makes the relpages value a lie but would be even less likely
> to confuse client-side code.

I don't know how it works internally, but if an empty table has a
filesize of 0 that's a lie, but if an empty table is just one page with a
header saying "nothing here, go away", it's the truth.

And I like your idea. I definitely think it would be useful. Your
proposed implementation is a bit hackish but quick and easy to do, and
with minimal breakage.

What do you think of the idea of using the estimation of the number of
rows to be inserted in the table as a help in planning the queries on this
table made during the INSERT (like FK checks) ? Did you read my previous
post on this ?

Thanks !

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2004-11-30 16:08:59 Re: change natural column order
Previous Message Nefnifi, Kasem 2004-11-30 15:55:24 Re: starting the database server