Re: Perfomance of views
От | Svenne Krap |
---|---|
Тема | Re: Perfomance of views |
Дата | |
Msg-id | 4360B375.8000303@krap.dk обсуждение исходный текст |
Ответ на | Re: Perfomance of views (Richard Huxton <dev@archonet.com>) |
Ответы |
Re: Perfomance of views
(Tom Lane <tgl@sss.pgh.pa.us>)
|
Список | pgsql-performance |
What do you mean exactly but "pushing conditions inside" ? I don't think I will have the option of testing on the full queries, as these take many days to write (the current ones, they are replacing on a mssql takes up more that 5kb of query). The current ones are nightmares from a maintaince standpoint. Basicly what the application is doing is selecting some base data from the "large" table for a point in time (usually a quarter) and selects all matching auxilliare data from the other tables. They are made in a time-travel like manner with a first and last useable date. 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. But I seem to remember (and I have used PGSQL in production since 7.0) that the planner has some problems with solution 3 (i.e. estimating the cost and rearranging the query), but frankly that would be the way I would like to go. Based on the current (non-optimal) design and hardware constraints, I still have to make sure, the query runs fairly optimal - that means the planner must use indexes intelligently and other stuff as if it was (well-)written using solution 1. What do you think of the three solutions ? And is there some ressource about the planners capabilites for someone like me (that is very used to write reasonably fast and complex sql, can read c-code, but does not really want to dig into the source code) Regards Svenne Richard Huxton wrote: > Svenne Krap wrote: > >> Hi there. >> >> I am currently building a system, where it would be nice to use >> multiple levels of views upon each other (it is a staticstics system, >> where traceability is important). >> >> Is there any significant performance reduction in say 10 levels of >> views instead of one giant, nested sql-statement ? I especially think >> exection planner-wise. > > > The planner tries to push conditions "inside" views where it can. It's > not perfect though, and if you're writing a big query by hand you > might be able to do better than it. > > In short, I'd test if you can.
В списке pgsql-performance по дате отправления: