Re: VACUUM and ANALYZE Follow-Up

Поиск
Список
Период
Сортировка
От Pierre-Frédéric Caillaud
Тема Re: VACUUM and ANALYZE Follow-Up
Дата
Msg-id opsiab551scq72hf@musicbox
обсуждение исходный текст
Ответ на Re: VACUUM and ANALYZE Follow-Up  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "Nefnifi, Kasem"
Дата:
Сообщение: Re: starting the database server
Следующее
От: Tom Lane
Дата:
Сообщение: Re: change natural column order