Re: VACUUM and ANALYZE Follow-Up - Mailing list pgsql-general

From Pierre-Frédéric Caillaud
Subject Re: VACUUM and ANALYZE Follow-Up
Date
Msg-id opsiab551scq72hf@musicbox
Whole thread Raw
In response to Re: VACUUM and ANALYZE Follow-Up  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 !



pgsql-general by date:

Previous
From: "Nefnifi, Kasem"
Date:
Subject: Re: starting the database server
Next
From: Tom Lane
Date:
Subject: Re: change natural column order