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.

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.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to