Skip site navigation (1) Skip section navigation (2)

Re: Perfomance of views

From: Svenne Krap <svenne(at)krap(dot)dk>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Perfomance of views
Date: 2005-10-27 11:01:09
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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)



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.

In response to


pgsql-performance by date

Next:From: Richard HuxtonDate: 2005-10-27 11:29:38
Subject: Re: Perfomance of views
Previous:From: Richard HuxtonDate: 2005-10-27 09:33:40
Subject: Re: Perfomance of views

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group