Thread: Re: [COMMITTERS] pgsql-server/ oc/src/sgml/runtime.sgml rc/back ...

Re: [COMMITTERS] pgsql-server/ oc/src/sgml/runtime.sgml rc/back ...

From
Bruce Momjian
Date:
Tom Lane wrote:
> Log message:
>     Finish implementation of hashed aggregation.  Add enable_hashagg GUC
>     parameter to allow it to be forced off for comparison purposes.
>     Add ORDER BY clauses to a bunch of regression test queries that will
>     otherwise produce randomly-ordered output in the new regime.

Tom, do we really want to add a GUC that is used just for comparison of
performance?  I know we have the seqscan on/off, but there are valid
reasons to do that.  Do you think there will be cases where it will
faster to have this hash setting off?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: [COMMITTERS] pgsql-server/ oc/src/sgml/runtime.sgml rc/back ...

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom, do we really want to add a GUC that is used just for comparison of
> performance?  I know we have the seqscan on/off, but there are valid
> reasons to do that.  Do you think there will be cases where it will
> faster to have this hash setting off?

Sure --- that's why the planner code is going to great lengths to try to
choose the faster one.  Even if I didn't think that, it'll be at least
as useful as, say, enable_indexscan.
        regards, tom lane


Re: [COMMITTERS] pgsql-server/ oc/src/sgml/runtime.sgml rc/back

From
Bruce Momjian
Date:
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom, do we really want to add a GUC that is used just for comparison of
> > performance?  I know we have the seqscan on/off, but there are valid
> > reasons to do that.  Do you think there will be cases where it will
> > faster to have this hash setting off?
> 
> Sure --- that's why the planner code is going to great lengths to try to
> choose the faster one.  Even if I didn't think that, it'll be at least
> as useful as, say, enable_indexscan.

Oh, OK.  Just checking.  I was confused about your commit message
because you seemed to be saying it was mostly for testing, and I thought
you meant testing to see if the hash code is an improvement over what we
had, rather than to see if the hash code is an improvement over the
sequential scan GROUP BY path, which is still in the code.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073