Hi!
On Mon, Jan 7, 2019 at 12:44 AM David Rowley
<david.rowley@2ndquadrant.com> wrote:
> If you're asking if it caches the result and foregoes scanning the
> underlying tables, then that's a "No". Else what further optimising
> did you have in mind?
For example, it could learn better statistics. In documentation [1] it
is written:
> A generic plan assumes that each value supplied to EXECUTE is one of the column's distinct values and that column
valuesare uniformly distributed. For example, if statistics record three distinct column values, a generic plan assumes
acolumn equality comparison will match 33% of processed rows. Column statistics also allow generic plans to accurately
computethe selectivity of unique columns.
So it could learn that the values used are not distinct values, or
that column values are not uniformly distributed? And maybe decide to
change the plan? So it makes a plan, runs it, determines that the plan
was not as good as expected, I run it again, it decides to try another
plan. It is better, it decides to switch to it and keep it.
[1] https://www.postgresql.org/docs/devel/sql-prepare.html
Mitar
--
http://mitar.tnode.com/
https://twitter.com/mitar_m
