Re: Views of views, complexity and speed.
От | bombadil@wanadoo.es |
---|---|
Тема | Re: Views of views, complexity and speed. |
Дата | |
Msg-id | 20020206081921.GA5439@fangorn обсуждение исходный текст |
Ответ на | Views of views, complexity and speed. (bombadil@wanadoo.es) |
Ответы |
Re: Views of views, complexity and speed.
|
Список | pgsql-general |
El martes 05 de febrero, Jan Wieck escribió: > bombadil@wanadoo.es wrote: > > In order to avoid complexity, some views looks in other views and > > join them for getting data. > > > > I see queries against that views result slower than queries against > > plane tables or simple views by an order of magnitude (when not two). > > > > My question is: if I would make complex views looking in plain tables > > instead of other views, could I gain speed with the cost of more > > difficult maintainability and readability? > > > > Sorry for lazy data and arguments. If any of you think that detailed > > tables and views may help, i can send them without problem. > > Asking for qualified opinions and comments "only" and then > beeing lazy on data and arguments, tztztz ... man! Emmmmm, sorry 0:) > The question I have is what do you really compare? You said > "looking in plain tables instead of other views". Does that > mean your query is faster when you build one big view against > all the base tables instead of cascaded views, or what? What > is the performance difference if you instead of using the > cascaded views query all the base tables in a big join > directly? Your comment resumes very well my essential question. I only want to know if there is a reason for thinkink that a cascade of views can be slower than a complex view that includes all tables. Is the planner well tuned for working with this complex cases (cascade of views)? Actually I am making experiments with all this stuff. Better idea than sending a lazy question in the list. Sorry again, and thanks for interest. Greets. David
В списке pgsql-general по дате отправления: