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

Re: Stored procedure declared as VOLATILE => no good optimization is done

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Damon Snyder <damon(at)huddler-inc(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Stored procedure declared as VOLATILE => no good optimization is done
Date: 2010-10-15 21:06:55
Message-ID: AANLkTin9sD8RCTcFqm1JG2fCLZKpMTZaFDcSDern=3iS@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Mon, Oct 11, 2010 at 7:10 PM, Damon Snyder <damon(at)huddler-inc(dot)com> wrote:
> Hello,
> I have heard it said that if a stored procedure is declared as VOLATILE,
> then no good optimizations can be done on queries within the stored
> procedure or queries that use the stored procedure (say as the column in a
> view). I have seen this in practice, recommended on the irc channel, and in
> the archives
> (http://archives.postgresql.org/pgsql-performance/2008-01/msg00283.php). Can
> someone help me understand or point me to some documentation explaining why
> this is so?
> Any insights would be appreciated. I'm new to pgsql and would like to know a
> little more about what is going on under the hood.
> Thanks,
> Damon

The theory behind 'volatile' is pretty simple -- each execution of the
function, regardless of the inputs, can be expected to produce a
completely independent result, or modifies the datbase.  In the case
of immutable, which is on the other end, particular set of inputs will
produce one and only result, and doesn't modify anything.

In the immutable case, the planner can shuffle the function call
around in the query, calling it less, simplifying joins, etc.  There
are lots of theoretical optimizations that can be done since the
inputs (principally table column values and literal values) can be
assumed static for the duration of the query.

'stable' is almost like immutable, but is only guaranteed static for
the duration of the query.  most functions that read from but don't
write to the database will fit in this category.  Most optimizations
still apply here, but stable functions can't be used in indexes and
can't be executed and saved off in plan time where it might be helpful
(prepared statements and pl/pgsql plans).

broadly speaking:
*) function generates same output from inputs regardless of what's
going on in the database, and has no side effects: IMMUTABLE
*) function reads (only) from tables, or is an immutable function in
most senses but influenced from the GUC (or any other out of scope
thing): STABLE
*) all other cases: VOLATILE (which is btw the default)

merlin

In response to

Responses

pgsql-performance by date

Next:From: Craig RingerDate: 2010-10-16 01:17:59
Subject: Re: [PERFORM] help with understanding EXPLAIN
Previous:From: Nikolai ZhubrDate: 2010-10-15 21:00:02
Subject: Re: Index scan / Index cond limitation or ?

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