Hi! On Mon, Jan 7, 2019 at 12:44 AM David Rowley <david.rowley@xxxxxxxxxxxxxxx> 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 values are uniformly distributed. For example, if statistics record three distinct column values, a generic plan assumes a column equality comparison will match 33% of processed rows. Column statistics also allow generic plans to accurately compute the 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
