Skip site navigation (1)
Skip section navigation (2)
Peripheral Links
Header And Logo
|
Site Navigation
Re: BUG #3500: Horrible performance when wrong type is set in prepared statement
- From: Joseph S <jks(at)selectacast(dot)net>
- To: Flavio Botelho <fbotelho(at)stj(dot)gov(dot)br>
- To: pgsql-bugs(at)postgresql(dot)org
- Subject: Re: BUG #3500: Horrible performance when wrong type is set in prepared statement
- Date: Tue, 31 Jul 2007 18:31:07 -0400
- Message-id: <46AFB82B.2090401@selectacast.net> <text/plain>
Flavio Botelho wrote:
Well that would be bad. I still have a lot of code with numbers inside quotes to work around the old postgres bug where index scans weren't used unless the numbers were in quotes (because the table columns were int2's and passed in numbers were assumed to be ints)I know the application should not be doing this. But i wonder if lots of the complaints about postgres performance couldnt be related to problems like this. I suggest that you change the behaviour of something like that from silently accepting the string value to throwing an error.
Do you have EXPLAIN output showing the difference in your queries if the values are in strings or not?
- References:
- BUG #3500: Horrible performance when wrong type is set in prepared statement
- From: Flavio Botelho
- BUG #3500: Horrible performance when wrong type is set in prepared statement
- Prev by Date: EXPLAIN ANALYZE for bitmapAnd and bitmapOr scans always reports rows = 0
- Next by Date: Oddities with ANYARRAY
- Previous by thread: BUG #3500: Horrible performance when wrong type is set in prepared statement
- Next by thread: BUG #3502: pg_ctl register translates \ to /
- Indexes: