Gaetano Mendola wrote:
Markus Bertheau â wrote:
Hi, I have the following strange situation:
that is no so strange. I have an example where:
SELECT * FROM my_view WHERE field1 = 'New'; ==> 800 seconds
SELECT * FROM my_view; ==> 2 seconds
the only solution I had was to write a function table with the second select in a loop that was returnin the row if the field1 was equal = 'New'. It's strange but happen.
Regards
Gaetano Mendola
That sounds more like you had bad statistics on the field1 column, which caused postgres to switch from a seqscan to an index scan, only there were so many rows with field1='New' that it actually would have been faster with a seqscan.
Otherwise what you did is very similar to the "nested loop" of postgres which it selects when appropriate.
The other issue with views is that depending on their definition, sometimes postgres can flatten them out and optimize the query, and sometimes it can't. Order by is one of the big culprits for bad queries involving views.
John =:->
signature.asc
Description: OpenPGP digital signature
