From: | "Jonathan Ellis" <jonathan(at)utahpython(dot)org> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Premature view materialization in 8.2? |
Date: | 2007-04-06 18:03:50 |
Message-ID: | e06563880704061103w10e19b96s4223527ebce6b33b@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 4/6/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Jonathan Ellis" <jonathan(at)utahpython(dot)org> writes:
> > I can do that... you don't think the fact I mentioned, that
> > redefining the view to leave out the expensive function fixes the
> > problem, is relevant?
>
> Hm, I'd not have thought that an expensive function would get evaluated
> partway up the join tree, but maybe that's wrong. You never did show
> us the actual view definition ...
It was in my original post unless it got clipped:
The problem seems to be that clan_members_v contains a call to an
expensive function:
create or replace view clan_members_v as
select cm.clan_id, cm.user_id, cp.party_id, cm.date_accepted,
p.name as party_name, p_tp_total(p.id)::int as tp_total
from clan_members cm, clan_participants cp, parties p
where cm.user_id = p.user_id
and p.id = cp.party_id
;
p_tp_total takes around 50ms per row.
If I create clan_members_v without the function call, the original
query's speed goes to the 150ms range on 8.2 as well.
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Stone | 2007-04-06 18:19:15 | Re: SCSI vs SATA |
Previous Message | Tom Lane | 2007-04-06 18:00:34 | Re: Premature view materialization in 8.2? |