Re: Perfomance of views
От | Tom Lane |
---|---|
Тема | Re: Perfomance of views |
Дата | |
Msg-id | 18899.1130423882@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Perfomance of views (Svenne Krap <svenne@krap.dk>) |
Ответы |
Re: Perfomance of views
|
Список | pgsql-performance |
Svenne Krap <svenne@krap.dk> writes: > The ways I have considered was : > 1) write a big query in hand (not preferred as it gets hard to manage) > 2) write layers of views (still not prefered as I still have to remember > to put on the right conditions everywhere) > 3) write layers of sql-functions (returning the right sets of rows from > the underlying tables) - which I prefer from a development angel .. it > gets very clean and I cant forget a parameter anywhere. #1 and #2 should behave pretty similarly, assuming that the "one big query" would have been structured the same way as the nest of views is. #3 unfortunately will pretty much suck, because there's no chance for cross-level optimization. There's been some discussion of inline-expanding SQL functions that return sets when they are called in FROM, which would make a SQL function that contains just a SELECT effectively equivalent to a view as far as the planner's powers of optimization go. No one's tried to make it happen yet though. regards, tom lane
В списке pgsql-performance по дате отправления: