> I can't get very excited about this one either, though I do believe it > can arise as the author says, "when you build complex views and JOIN > them to each other". Maybe I'm not excited about it because I've not > needed it :)
This is one that I know would help with my database. There is a ton of logic stored in views, which get joined to to the original table to filter the set rather than imposing that set of conditions in every separate query. It would be really nice if the optimizer could simplify those to eliminate the self join. It's almost always on the primary key of a table that the join would happen on, and if not it'd be a non-nullable column for sure. On another note: > turning ORs into UNIONs This is another one which would be incredibly useful for me. I've had to do this manually for performance reasons far too often. > Partially agreed. A comment to the article also mentions that some other > database performs more optimizations depending on the cost of the > plan. That's not easy to do in our current plan structure, but I think > it's quite a worthwhile concept. I would love to see this in Postgres. It would allow the planner to not waste cycles unnecessarily on queries where it's just not needed, and to potentially spend a few more cycles planning on very costly queries to save a ton while executing. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers