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
=:->