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 по дате отправления: