On Wed, Mar 6, 2013 at 09:16:59AM -0500, Tom Lane wrote: > Simon Riggs <si...@2ndquadrant.com> writes: > > On 5 March 2013 22:02, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> FWIW, my opinion is that doing anything like this in the planner is > >> going to be enormously expensive. > > > As we already said: no MVs => zero overhead => no problem. > > Well, in the first place that statement is false on its face: we'll > still spend cycles looking for relevant MVs, or at least maintaining a > complexly-indexed cache that helps us find out that there are none in > a reasonable amount of time. In the second place, even if it were > approximately true it wouldn't help the people who were using MVs. > > > It costs in > > the cases where time savings are possible and not otherwise. > > And that is just complete nonsense: matching costs whether you find a > match or not. Could we have a little less Pollyanna-ish optimism and > a bit more realism about the likely cost of such a feature?
Should we add this to the TODO list as a possibility? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
