Re: [REVIEW] prepare plans of embedded sql on function start - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: [REVIEW] prepare plans of embedded sql on function start
Date
Msg-id m262kzgzxy.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: [REVIEW] prepare plans of embedded sql on function start  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:
> I'm not that happy with overloading the ANALYZE keyword to mean this
> (especially not since there is already meaning attached to the syntax
> "ANALYZE x(y)").  But we could certainly use some other name --- I'm
> inclined to suggest CHECK:
>
>     CHECK FUNCTION function_name(arglist);

This looks as good as it gets, but as we proposed some new behaviors for
ANALYZE in the past, I though I would bounce them here again for you to
decide about the overall picture.

The idea (that didn't get much traction at the time) was to support
ANALYZE on VIEWS so that we have statistics support for multi-columns or
any user given join.  The very difficult part about that is to be able
to match those stats we would have against a user SQL query.

But such a matching has been talked about in other contexts, it seems to
me, so the day we have that capability we might want to add ANALYZE
support to VIEWS.  ANALYZE could then support tables, indexes, views and
functions, and maybe some more database objects in the future.

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: [REVIEW] prepare plans of embedded sql on function start
Next
From: Martijn van Oosterhout
Date:
Subject: Re: Thinking about inventing MemoryContextSetParent