Re: Premature view materialization in 8.2?
От | Jonathan Ellis |
---|---|
Тема | Re: Premature view materialization in 8.2? |
Дата | |
Msg-id | e06563880704061103w10e19b96s4223527ebce6b33b@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Premature view materialization in 8.2? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Premature view materialization in 8.2?
|
Список | pgsql-performance |
On 4/6/07, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Jonathan Ellis" <jonathan@utahpython.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.
В списке pgsql-performance по дате отправления: