[PERFORM] Re: [PERFORM] RE: [PERFORM] Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it.

I was afraid of something worse but hoping for something better in terms of maintainability. At least now I have a good explanation. :-) I just hope the embedded view use won't interfere too much.   Thanks everyone.   Regards,   Peter Slapansky   ___

[PERFORM] RE: [PERFORM] Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it.

I got: "Total runtime: 9.313 ms" in pgAdmin "Total runtime: 9.363 ms" in psql. But timing after the query finished was 912.842 ms in psql.   Cheers,   Peter Slapansky __ Od: Igor Neyman Komu: "sl...@centrum.sk" , Pavel Stehule Dátum:

[PERFORM] RE: [PERFORM] Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it.

You're right, it does... but it's quite odd, because I re-ran the explain-analyze statement and got the same results. Still, the query now runs for about a second as mentioned before, so it's almost like something's missing from the explain, but I'm certain I copied it all.   I did this via pga

[PERFORM] Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it.

Good day,   I have included a link to the result of EXPLAIN ANALYZE. It's this one: https://app.box.com/s/u8nk6qvkjs4ae7l7dh4h   Here's a link to Depesz's explain (if links to the site are okay): http://explain.depesz.com/s/gCk

[PERFORM] Re: Sub-optimal plan for a paginated query on a view with another view inside of it.

I apologise, I have neglected to mention Postgres versions tested. It occurs with 9.0 and 9.2 I have typo in my previous message - the sentence about vacuum, reindex and analyze should be: "I had also run vacuum, reindex and analyze on the whole database, but it seems to have had no effect."  

[PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it.

Good day,   I have a performance issue when JOINing a view within another view more than once. The query takes over three seconds to execute, which is too long in this case. It's not a problem if the tables are nearly empty, but that isn't the case on the production database.   I suspect the pla