Union within View vs.Union of Views
От
Jeff Larsen
Тема
Union within View vs.Union of Views
Дата
Msg-id
d1f9b6f00711031322h1d2858d4xbfff4852941d405b@mail.gmail.com
Список
Дерево обсуждения
Union within View vs.Union of Views "Jeff Larsen" <jlar310@gmail.com>
Re: Union within View vs.Union of Views Mark Mielke <mark@mark.mielke.cc>
Re: Union within View vs.Union of Views Heikki Linnakangas <heikki@enterprisedb.com>
Re: Union within View vs.Union of Views Tom Lane <tgl@sss.pgh.pa.us>
Re: Union within View vs.Union of Views "Jeff Larsen" <jlar310@gmail.com>
Consider: CREATE VIEW_X AS SELECT UNION ALL SELECT UNION ALL SELECT ; versus CREATE VIEW_A AS SELECT ; CREATE VIEW_B AS SELECT ; CREATE VIEW_C AS SELECT ; where , and are each somewhat complex with several joins, but utilizing different tables for each of A, B and C. Performance on SELECT * from VIEW_X WHERE ; was absolutely terrible. But performance on SELECT * from VIEW_A WHERE UNION ALL SELECT * from VIEW_B WHERE UNION ALL SELECT * from VIEW_C WHERE ; was nice and speedy, perhaps 100 times faster than the first. If it's possible to consider this abstractly, is there any particular reason why there is such a vast difference in performance? I would guess that is has something to do with how the WHERE conditions are applied to a view composed of a UNION of queries. Perhaps this is an opportunity for improvement in the code. In the first case, it's as if the server is doing the union on all rows (over 10 million altogether in my case) without filtering, then applying the conditions to the result. Maybe there is no better way. I can post query plans if anyone is interested. I haven't really learned how to make sense out of them myself yet. For my purposes, I'm content to use the union of separate views in my application, so if this doesn't pique anyone's interest, feel free to ignore it. Jeff
В списке pgsql-performance по дате отправления