Hi,
Nobody is tring to attack anyone, but we're all surprised this is an
issue since you're the first person to have mentioned it. I have some
a query to test below:
On Tue, Jun 12, 2007 at 10:21:09AM -0700, Larry McGhaw wrote:
> We noticed inexplicably that when we used a constant with a postgres
> query, our records per second dropped
> From 60,000 records per second to 600 records per second, so we started
> digging into the issue.
>
> We discovered that libpq was not describing the metadata properly for
> the constant column, and it appears
> That the 3rd party grid control was relying on that metadata somehow ..
> The bottom line is that there was
> A huge performance drag.
What I don't understand is *why* it's complaining about the constant
column and not, for example, any other variable length column. There
are a very small number of cases where a useful length is returned, 99%
of the time it doesn't, yet you're obviously not get any performance
problems there.
Just a quick test, does the problem go away if you do:
SELECT '1'::varchar FROM table;
If that fixes it then the bug is (probably) that the middleware thinks
that a length of -2 means it's 65534 bytes long. Note, in the test
query I gave, it will return -1 for the length. I don't want to blame
the middleware, but I want to make sure we're diagnosing the problem
correctly.
If that query has the same problem, then we really need to think of
something else.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
