Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
In response to
pgsql-hackers by date
|Next:||From: Martijn van Oosterhout||Date: 2011-09-11 10:36:15|
|Subject: Re: Thinking about inventing MemoryContextSetParent|
|Previous:||From: Pavel Stehule||Date: 2011-09-11 07:30:18|
|Subject: Re: [REVIEW] prepare plans of embedded sql on function start|