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

Re: [HACKERS] spurious function execution in prepared statements.

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Michael Adler" <adler(at)pobox(dot)com>
Cc: <pgsql-performance(at)postgresql(dot)org>,<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] spurious function execution in prepared statements.
Date: 2004-09-30 14:19:12
Message-ID: 6EE64EF3AB31D5448D0007DD34EEB3412A74DE@Herge.rcsinc.local (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
> Here's another workaround that may let you use a prepared statement:
> 
> prepare ps(...) as
> select f(c) from (select c from t where [expr] limit 1) as t1
> 
> -Mike

I was just exploring that.  In fact, the problem is not limited to
prepared statements...it's just that they are more likely to run a
seqscan so I noticed it there first.  Since I am in a situation where I
need very strict control over when and why f gets executed, I pretty
much have to go with the subquery option.  

That said, it just seems that out of result set excecutions of f should
be in violation of something... 

Merlin


pgsql-performance by date

Next:From: Stephan SzaboDate: 2004-09-30 14:45:40
Subject: Re: spurious function execution in prepared statements.
Previous:From: Michael AdlerDate: 2004-09-30 14:13:24
Subject: Re: [HACKERS] spurious function execution in prepared statements.

pgsql-hackers by date

Next:From: Tom LaneDate: 2004-09-30 14:23:05
Subject: Re: profile-guided opt. w/ GCC
Previous:From: Michael AdlerDate: 2004-09-30 14:13:24
Subject: Re: [HACKERS] spurious function execution in prepared statements.

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