Thread: Re: join and query planner

Re: join and query planner

From
"Kevin Grittner"
Date:
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)


>>> "Dario Pudlo" <dariop@unitech.com.ar> 07/06/05 4:54 PM >>>
(first at all, sorry for my english)
Hi.
   - Does "left join" restrict the order in which the planner must join
tables? I've read about join, but i'm not sure about left join...
   - If so: Can I avoid this behavior? I mean, make the planner resolve
the
query, using statistics (uniqueness, data distribution) rather than join
order.

    My query looks like:
    SELECT ...
      FROM a, b,
      LEFT JOIN c ON (c.key = a.key)
      LEFT JOIN d on (d.key=a.key)
      WHERE (a.key = b.key)  AND (b.column <= 100)

      b.column has a lot better selectivity, but planner insist on
resolve
first c.key = a.key.

    Of course, I could rewrite something like:
    SELECT ...
      FROM
           (SELECT ...
            FROM a,b
            LEFT JOIN d on (d.key=a.key)
            WHERE (b.column <= 100)
            )
            as aa
      LEFT JOIN c ON (c.key = aa.key)

    but this is query is constructed by an application with a
"multicolumn"
filter. It's dynamic.
      It means that a user could choose to look for "c.column = 1000".
And
also, combinations of filters.

    So, I need the planner to choose the best plan...

I've already change statistics, I clustered tables with cluster, ran
vacuum
analyze, changed work_mem, shared_buffers...

Greetings. TIA.


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster


Re: join and query planner

From
"Dario"
Date:
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@postgresql.org
[mailto:pgsql-performance-owner@postgresql.org]En nombre de Kevin
Grittner
Enviado el: lunes, 18 de julio de 2005 14:58
Para: pgsql-performance@postgresql.org; dariop@unitech.com.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


Re: join and query planner

From
"Kevin Grittner"
Date:
You might want to set join_collapse_limit high, and use the JOIN
operators rather than the comma-separated lists.  We generate the WHERE
clause on the fly, based on user input, and this has worked well for us.

-Kevin


>>> "Dario" <dario_d_s@unitech.com.ar> 07/18/05 2:24 PM >>>
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@postgresql.org
[mailto:pgsql-performance-owner@postgresql.org]En nombre de Kevin
Grittner
Enviado el: lunes, 18 de julio de 2005 14:58
Para: pgsql-performance@postgresql.org; dariop@unitech.com.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


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings


Re: join and query planner

From
"Dario"
Date:
I'll try that.

Let you know as soon as I can take a look.


Thank you-

-----Mensaje original-----
De: pgsql-performance-owner@postgresql.org
[mailto:pgsql-performance-owner@postgresql.org]En nombre de Kevin
Grittner
Enviado el: lunes, 18 de julio de 2005 17:48
Para: pgsql-performance@postgresql.org; dario_d_s@unitech.com.ar
Asunto: Re: [PERFORM] join and query planner


You might want to set join_collapse_limit high, and use the JOIN
operators rather than the comma-separated lists.  We generate the WHERE
clause on the fly, based on user input, and this has worked well for us.

-Kevin


>>> "Dario" <dario_d_s@unitech.com.ar> 07/18/05 2:24 PM >>>
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@postgresql.org
[mailto:pgsql-performance-owner@postgresql.org]En nombre de Kevin
Grittner
Enviado el: lunes, 18 de julio de 2005 14:58
Para: pgsql-performance@postgresql.org; dariop@unitech.com.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


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match