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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a
Date: 2009-12-03 02:55:42
Message-ID: 27683.1259808942@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Robert Haas 2009-12-03 03:24:09 Re: Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a
Previous Message Robert Haas 2009-12-03 02:12:39 Re: Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-12-03 03:03:18 Re: Catastrophic changes to PostgreSQL 8.4
Previous Message Craig Ringer 2009-12-03 02:54:07 Re: Catastrophic changes to PostgreSQL 8.4