From: | "Dario" <dario_d_s(at)unitech(dot)com(dot)ar> |
---|---|
To: | <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: join and query planner |
Date: | 2005-07-18 19:24:19 |
Message-ID: | MHEDJHCKDNOEHJKHIOCJEEMDCEAA.dario_d_s@unitech.com.ar |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hi.
> Just out of curiosity, does it do any better with the following?
>
> SELECT ...
Yes, it does.
But my query could also be
SELECT ...
FROM a
JOIN b ON (a.key = b.key)
LEFT JOIN c ON (c.key = a.key)
LEFT JOIN d ON (d.key=a.key)
/*new*/ , e
WHERE (b.column <= 100)
/*new*/ and (e.key = a.key) and (e.field = 'filter')
because it's constructed by an application. I needed to know if, somehow,
someway, I can "unforce" join order.
The only way to solve it so far is changing application. It must build
something like
SELECT ...
FROM b
JOIN (a JOIN e ON (e.key = a.key)) ON (a.key = b.key)
LEFT JOIN c ON (c.key = a.key)
LEFT JOIN d ON (d.key=a.key)
WHERE (b.column <= 100) and (e.field = 'filter')
Supossed that e.field has (should have) better selectivity. But now this
problem belongs to programmer's group :-)
The query, in fact, has more tables to join. I wonder if lowering geqo
threshold could do the work...
Thank you. Greetings. Long life, little spam and prosperity!
-----Mensaje original-----
De: pgsql-performance-owner(at)postgresql(dot)org
[mailto:pgsql-performance-owner(at)postgresql(dot)org]En nombre de Kevin
Grittner
Enviado el: lunes, 18 de julio de 2005 14:58
Para: pgsql-performance(at)postgresql(dot)org; dariop(at)unitech(dot)com(dot)ar
Asunto: Re: [PERFORM] join and query planner
Just out of curiosity, does it do any better with the following?
SELECT ...
FROM a
JOIN b ON (a.key = b.key)
LEFT JOIN c ON (c.key = a.key)
LEFT JOIN d ON (d.key=a.key)
WHERE (b.column <= 100)
>>> snipp
From | Date | Subject | |
---|---|---|---|
Next Message | Yves Vindevogel | 2005-07-18 19:29:20 | Insert performance (OT?) |
Previous Message | Christopher Petrilli | 2005-07-18 18:45:35 | Re: Impact of checkpoint_segments under continual load conditions |