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 17:57:27 |
Message-ID: | e06563880704061057q46db0f90w5128ce74471b53ad@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:
> > On 4/6/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> Yeah, it sure is the same plan, and 8.2 seems to be a tad faster right
> >> up to the hash join on user_id. Is user_id a textual datatype?
>
> > user_id is an int; they are both C locale.
>
> Really!? So much for that theory.
Yeah, this db goes back to 7.0 so I've been careful to keep the locale
set to C to avoid surprises.
> Is work_mem set similarly on both installations?
work_mem is 8MB on 8.2; work_mem is 1MB and sort_mem is 8MB on 8.1.
(there's no disk io going on with the 8.2 installation either, so it's
not swapping or anything like that.)
> The only other thing I can think is that you've exposed some unfortunate
> corner case in the hash join logic. Would you be willing to send me
> (off-list) the lists of user_ids being joined? That would be the
> clan_members.user_id column and the user_id column from the join of
> parties and clan_participants.
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?
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-04-06 18:00:34 | Re: Premature view materialization in 8.2? |
Previous Message | Tom Lane | 2007-04-06 17:40:27 | Re: Premature view materialization in 8.2? |