Re: Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Actually, I think Tom made some changes for 8.5 that should eliminate
> the randomness, if not the badness. Or am I misremembering?

It was mostly Andres' work, see
http://archives.postgresql.org/pgsql-committers/2009-07/msg00148.php

> One other thing I'm noticing about the current implementation is that
> it seems to spend an entirely excessive amount of brain power
> considering the best order in which to execute cross-joins. If I do
> X, A JOIN B ON Pab JOIN C ON Pac JOIN D ON Pad JOIN E ON Pae, it looks
> to me like join_search_one_level() will try joining X to each of A-E.
> That seems fairly pointless; why would I ever want to join X to
> anything other than {A B C D E}?

Not sure that a lot of cross joins with no conditions is the case to
design around. Usually queries aren't that devoid of features of
interest, and so different join paths are actually usefully different.

> ... We should maybe also
> think about raising the default value for work_mem. It's hard for me
> to believe that the average Postgres user wants a sort that takes more
> than 1MB of memory to spill to disk; there certainly are people who
> probably want that, but I doubt there are very many. I believe we've
> been using that value for a decade, and memory size has increased a
> lot in that time.

Maybe. I'll certainly grant that machines have more memory, but is the
average Postgres installation using that to run bigger sorts, or to run
more sorts (either more concurrent queries or more complex queries
containing more sorts)? We know that increasing work_mem too much
can be counterproductive, and much sooner than one might think.

regards, tom lane