From: | "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> |
---|---|
To: | "K C Lau" <kclau60(at)netvigator(dot)com> |
Cc: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: SELECT LIMIT 1 VIEW Performance Issue |
Date: | 2005-09-22 14:37:08 |
Message-ID: | 6EE64EF3AB31D5448D0007DD34EEB3417DD3FF@Herge.rcsinc.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> >I previously posted the following as a sequel to my SELECT DISTINCT
> >Performance Issue question. We would most appreciate any clue or
> >suggestions on how to overcome this show-stopping issue. We are using
> >8.0.3 on Windows.
> >
> >Is it a known limitation when using a view with SELECT ... LIMIT 1?
> >
> >Would the forthcoming performance enhancement with MAX help when used
> >within a view, as in:
> >
> >create or replace view VCurPlayer as select * from Player a
> >where a.AtDate = (select Max(b.AtDate) from Player b where a.PlayerID
=
> >b.PlayerID);
Here is a trick I use sometimes with views, etc. This may or may not be
effective to solve your problem but it's worth a shot. Create one small
SQL function taking date, etc. and returning the values and define it
immutable. Now in-query it is treated like a constant.
Another useful application for this feature is when you have nested
views (view 1 queries view 2) and you need to filter records based on
fields from view 2 which are not returned in view 1. Impossible?
in view 2 add clause where v2.f between f_min() and f_max(), them being
immutable functions which can grab filter criteria based on inputs or
values from a table.
Merlin
From | Date | Subject | |
---|---|---|---|
Next Message | K C Lau | 2005-09-22 14:39:29 | Re: SELECT LIMIT 1 VIEW Performance Issue |
Previous Message | Simon Riggs | 2005-09-22 12:48:04 | Re: SELECT LIMIT 1 VIEW Performance Issue |