Re: plans for PostgreSQL 12

2018-06-04 9:59 GMT+02:00 Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com>:

> On 04/06/18 09:37, Pavel Stehule wrote:
> >
> >
> > 2018-06-04 9:24 GMT+02:00 Heikki Linnakangas <hlinnaka(at)iki(dot)fi
> > <mailto:hlinnaka(at)iki(dot)fi>>:
> >
> > On 04/06/18 09:12, Pavel Stehule wrote:
> >
> > It requires introduction of new "safe" functions (& operators).
> > Immutable
> > functions are not enough safe.
> >
> > CREATE OR REPLACE FUNCTION public.fx()
> > RETURNS integer
> > LANGUAGE plpgsql
> > IMMUTABLE
> > AS $function$
> > BEGIN
> > RETURN (SELECT count(*) FROM pg_class);
> > END;
> > $function$
> >
> > postgres=# SELECT fx();
> > ┌─────┐
> > │ fx │
> > ╞═════╡
> > │ 343 │
> > └─────┘
> > (1 row)
> >
> >
> > That function is incorrectly marked as IMMUTABLE. In that situation,
> > it's enough that we throw a sane error like "ERROR: no snapshot
> > available".
> >
> > Yes, it is incorrect mark. Unfortunately - this is often workaround for
> > wrong estimations - so I afraid, in this case, your proposed fix breaks
> > lot of applications.
>
> I would say such applications are already broken.
>

I cannot to agree, not in this moment:

1. there is not any workaround, how to force subselect evaluation in
planning time - what can be correct for once only evaluated queries.

2. what is not prohibited, is enabled. I agree so this trick is ugly - but
I got it from Tom if I remember well maybe more than 10 years ago. Now is
too late change it - I think - probably we find more strange features that
we hold due compatibility. But this discussion is offtopic for this thread.
I am thinking so lot of expressions can be significantly accelerated and I
would to check it.

Regards

Pavel

--
> Vik Fearing +33 6 46 75 15 36
> http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
>