Re: [HACKERS] [COMMITTERS] pgsql-server/ oc/src/sgml/runtime.sgml rc/back
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [COMMITTERS] pgsql-server/ oc/src/sgml/runtime.sgml rc/back ...
Bruce Momjian <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [COMMITTERS] pgsql-server/ oc/src/sgml/runtime.sgml rc/back ...
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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
