Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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.

Dimitri Fontaine     PostgreSQL : Expertise, Formation et Support

In response to

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group