Re: [REVIEW] prepare plans of embedded sql on function start

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andy Colson <andy(at)squeakycode(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, pavel(dot)stehule(at)gmail(dot)com
Subject: Re: [REVIEW] prepare plans of embedded sql on function start
Date: 2011-09-11 10:01:45
Message-ID: m262kzgzxy.fsf@2ndQuadrant.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Martijn van Oosterhout 2011-09-11 10:36:15 Re: Thinking about inventing MemoryContextSetParent
Previous Message Pavel Stehule 2011-09-11 07:30:18 Re: [REVIEW] prepare plans of embedded sql on function start