Re: Odd sorting behaviour - Mailing list pgsql-performance

From Steinar H. Gunderson
Subject Re: Odd sorting behaviour
Date
Msg-id 20040721100410.GC26552@uio.no
Whole thread Raw
In response to Re: Odd sorting behaviour  (Rod Taylor <pg@rbt.ca>)
Responses Re: Odd sorting behaviour
List pgsql-performance
On Tue, Jul 20, 2004 at 10:18:19PM -0400, Rod Taylor wrote:
> I've taken a look and managed to cut out quite a bit of used time.
> You'll need to confirm it's the same results though (I didn't -- it is
> the same number of results (query below)

It looks very much like the same results.

> Secondly, I had no luck getting the hashjoin but this probably doesn't
> matter. I've assumed that the number of users will climb faster than the
> product set offered, and generated additional data via the below command
> run 4 times:

Actually, the number of users won't climb that much faster; what will
probably increase is the number of opinions.

> I found that by this point, the hashjoin and mergejoin have essentially
> the same performance -- in otherwords, as you grow you'll want the
> mergejoin eventually so I wouldn't worry about it too much.

Hm, OK.

>          -- Plain join okay since o12.correlation <> 0
>          -- eliminates any NULLs anyway.
>          -- Was RIGHT JOIN

OK, that makes sense (although I don't really see why it should be faster).

>          -- Was old Left join
>    WHERE o3.prodid NOT IN (SELECT prodid
>                              FROM opinions AS o4
>                             WHERE uid = 1355)

As my server is 7.2 and not 7.4, that obviously won't help much :-) Thanks
anyway, though -- we'll upgrade eventually, and it'll help then.

/* Steinar */
--
Homepage: http://www.sesse.net/

pgsql-performance by date:

Previous
From: Rod Taylor
Date:
Subject: Re: Odd sorting behaviour
Next
From: Rod Taylor
Date:
Subject: Re: Odd sorting behaviour