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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-09-30 14:23:05 | Re: profile-guided opt. w/ GCC |
Previous Message | Michael Adler | 2004-09-30 14:13:24 | Re: [HACKERS] spurious function execution in prepared statements. |
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2004-09-30 14:45:40 | Re: spurious function execution in prepared statements. |
Previous Message | Michael Adler | 2004-09-30 14:13:24 | Re: [HACKERS] spurious function execution in prepared statements. |