Re: Odd sorting behaviour

Поиск
Список
Период
Сортировка
От Steinar H. Gunderson
Тема Re: Odd sorting behaviour
Дата
Msg-id 20040721100410.GC26552@uio.no
обсуждение исходный текст
Ответ на Re: Odd sorting behaviour  (Rod Taylor <pg@rbt.ca>)
Ответы Re: Odd sorting behaviour  (Rod Taylor <pg@rbt.ca>)
Список 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 по дате отправления:

Предыдущее
От: Rod Taylor
Дата:
Сообщение: Re: Odd sorting behaviour
Следующее
От: Rod Taylor
Дата:
Сообщение: Re: Odd sorting behaviour