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 <[EMAIL PROTECTED]> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate.
signature.asc
Description: Digital signature
