On Thursday, February 6, 2014 2:18:51 PM UTC-5, Klauss wrote: > > I think views don't cache the plan, they're handled as rules. > > What you'd need is a function (pg's version of stored procedures). >
I had time to look it up; this generally seems correct. Looking at some explain syntax, it seems like the plan for join conditions under the view are kept -- but you still get hit with a plan onto the view. i could be interpreting this wrong, and this likely has minimal use. something that might be applicable to the original poster's usage is a parallel search. we have a lightweight read-through cache working with sqlalchemy for 'simple' queries ( 1-2 kv pairs ). cache fails are aggregated and then tossed into a single select. dumb example: select * from table where id = 1; select * from table where id = 2; select * from table where id = 3; select * from table where id = 4; select * from table where id = 5; becomes select * from table where id in (1,2,3,4,5) The performance improvement is shockingly significant; i think it's a mix of the planning, fetching and fewer roundtrips/connectivity. if that's an option, i'd suggest trying it. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/groups/opt_out.
