Re: Fixing some ancient errors in hash join costing

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Fixing some ancient errors in hash join costing
Date: 2025-12-29 03:29:16
Message-ID: 2742257.1766978956@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> writes:
> Just a few small comments on v2:

> This is not a concern, just curious why switch the setting order of enable_hashjoin and enable_sort?

The need to disable hashjoin only applies to one of the two tests, so
it seemed to me that this way is more nicely nested. Judgment call
of course.

> As flag 0 is passed to get_attstatsslot(), free_attstatsslot() is not needed.

True. I wrote it like that so people wouldn't wonder if I'd forgotten
free_attstatsslot(), but if other call sites passing flags == 0 don't
use it then it'd be better to be consistent. (I didn't check that.)

> Maybe worth adding a short comment like “0.0 doesn’t mean zero frequency, instead 0.0 means no data or unknown frequency”, which might help code readers to quickly understand the logic.

Doesn't the function's header comment cover that adequately?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-12-29 03:32:02 Re: cleanup: Split long Makefile lists across lines and sort them
Previous Message Tom Lane 2025-12-29 03:23:46 Re: Introduce ENDLIST to terminate multiline makefile lists