Re: [PG19] Hash join writes null-keyed outer rows to temp files

shihao zhong <zhong950419(at)gmail(dot)com> writes:
> The original mail said returning them right away would need a big
> rewrite [1]. The patch gives such a row a dummy hash value of 0 and
> lets it probe as usual. That value always maps to the current batch,
> and the row cannot match, so it comes out null-extended right away,
> like in 18.

I do not think I believe this patch. In particular, it assumes that
hashvalue 0 will map to the current batch, which is only accidentally
true for ExecHashGetBucketAndBatch (but okay, we could add a provision
to its API that hashvalue 0 must map to batch 0) and more importantly
can fail entirely for ExecHashGetSkewBucket. There's no reason to
assume there couldn't be a real tuple with hashvalue 0, and if there
were one already in the skew table then the wrong things would happen.

Also, trading off storing to a tuplestore for scanning a hash bucket
is not obviously a win.

> Another way is to return such a row with a flag and jump straight to
> HJ_FILL_OUTER_TUPLE, skipping the probe.

I like this idea substantially better. More or less as attached?

regards, tom lane