Re: Selecting a constant question
От | Martijn van Oosterhout |
---|---|
Тема | Re: Selecting a constant question |
Дата | |
Msg-id | 20070612174306.GE26937@svana.org обсуждение исходный текст |
Ответ на | Re: Selecting a constant question ("Larry McGhaw" <lmcghaw@connx.com>) |
Ответы |
Re: Selecting a constant question
|
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: