On 2008-02-15 15:03, Dean Gibson (DB Administrator) wrote:
On 2008-02-15 14:32, Tom Lane wrote:
Casing a TEXT item to a CHAR( 9 ) item isn't a no-op. I've seen this
before in "EXPLAIN ..." output, where a search on an indexed column
will be sequential because the planner treats the search val
On 2008-02-15 14:32, Tom Lane wrote:
"Dean Gibson (DB Administrator)" <[EMAIL PROTECTED]> writes:
Again, you are not understanding my point. My point was that specifying
tablename.columnname%TYPE notation doesn't help with the performance
problem; I have to explicitly cast the parameter in
"Dean Gibson (DB Administrator)" <[EMAIL PROTECTED]> writes:
> Again, you are not understanding my point. My point was that specifying
> tablename.columnname%TYPE notation doesn't help with the performance
> problem; I have to explicitly cast the parameter in the body of the
> function.
The r
On 2008-02-15 01:38, Richard Huxton wrote:
Dean Gibson (DB Administrator) wrote:
On 2008-02-14 15:19, Tom Lane wrote:
It's not exactly clear what you checked, but it works as expected
for me. See test case below, proving that indexscan works just fine
with a parameter declared using %type.
Dean Gibson (DB Administrator) wrote:
On 2008-02-14 15:19, Tom Lane wrote:
It's not exactly clear what you checked, but it works as expected for
me. See test case below, proving that indexscan works just fine with
a parameter declared using %type.
Consider:
CREATE TABLE zzz( aaa CHAR( 10 )
On 2008-02-14 15:19, Tom Lane wrote:
It's not exactly clear what you checked, but it works as expected for me. See
test case below, proving that indexscan works just fine with a parameter
declared using %type.
regards, tom lane
Consider:
CREATE TABLE zzz( aaa CHA
"Dean Gibson (DB Administrator)" <[EMAIL PROTECTED]> writes:
> So, is this the best (or only) way to solve this? I haven't done
> exhaustive checking, but it appears that specifying the type of
> parameters in the function prototype is only used for type-checking (and
> function matching), and
Last night I tore my hair out for about three hours with the following
problem (v8.3.0):
I had a simple scalar query that I wanted to create a function for.
However, when I created the function and called it from another query OR
the PSQL command line, it was two orders of magnitude SLOWER th
