From: Tom Lane <tgl@sss.pgh.pa.us>
To: Svenne Krap <svenne@krap.dk>
Cc: pgsql-performance@postgresql.org
Subject: Re: Perfomance of views
Date: Thu, 27 Oct 2005 10:38:02 -0400
Message-ID: <18899.1130423882@sss.pgh.pa.us> (raw)
In-Reply-To: <4360B375.8000303@krap.dk>
References: <435FA002.4060509@krap.dk>
<43609EF4.8060907@archonet.com>
<4360B375.8000303@krap.dk>
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
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: tgl@sss.pgh.pa.us, svenne@krap.dk
Subject: Re: Perfomance of views
In-Reply-To: <18899.1130423882@sss.pgh.pa.us>
* 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