From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Svenne Krap <svenne(at)krap(dot)dk> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Perfomance of views |
Date: | 2005-10-27 14:38:02 |
Message-ID: | 18899.1130423882@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Svenne Krap <svenne(at)krap(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Svenne Krap | 2005-10-27 15:10:29 | Re: Perfomance of views |
Previous Message | Edward Di Geronimo Jr. | 2005-10-27 14:35:41 | Re: Performance issues with custom functions |