Re: Stopgap solution for table-size-estimate updating problem - Mailing list pgsql-hackers

From Zeugswetter Andreas DAZ SD
Subject Re: Stopgap solution for table-size-estimate updating problem
Date
Msg-id 46C15C39FEB2C44BA555E356FBCD6FA40184D24C@m0114.s-mxs.net
Whole thread Raw
In response to Stopgap solution for table-size-estimate updating problem  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Stopgap solution for table-size-estimate updating problem
List pgsql-hackers
>    rel->pages = RelationGetNumberOfBlocks(relation);

Is RelationGetNumberOfBlocks cheap enough that you can easily use it for the
optimizer ?

I myself have always preferred more stable estimates that only change
when told to. I never liked that vacuum (without analyze) and create index
change those values, imho only analyze should. But I am used to applications
that prepare a query and hold the plan for days or weeks. If you happen to
create the plan when the table is by chance empty you lost.
But it seems I am quite alone with that opinion.

> 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 would let analyze still fill in the correct values.
The 0 or 1 page previous denstity could be used for only when the table is empty.
I don't think eighter would confuse client-side code more or less.
More confusing for client-side code would be if the two would not show the
analyze results any more.

I would like to see this configurable. Like "use_analyzed_stats" or
"enable_online_statistics" or some such that can be used more future
online statistics.
One setting would use:
pages = RelationGetNumberOfBlocks(relation)
count = pages * reltuples / relpages

the other:
pages = relpages
count = relcount

Andreas


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Stopgap solution for table-size-estimate updating problem
Next
From: Roland Volkmann
Date:
Subject: Error: column "nsptablespace" does not exist