From: Svenne Krap <svenne@krap.dk>
To: pgsql-performance@postgresql.org
Subject: Re: Perfomance of views
Date: Thu, 27 Oct 2005 13:01:09 +0200
Message-ID: <4360B375.8000303@krap.dk> (raw)
In-Reply-To: <43609EF4.8060907@archonet.com>
References: <435FA002.4060509@krap.dk>
<43609EF4.8060907@archonet.com>
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.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: svenne@krap.dk
Subject: Re: Perfomance of views
In-Reply-To: <4360B375.8000303@krap.dk>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox