Re: BUG #19759: Hashed SetOp / RecursiveUnion pre-allocate up to 64 GB from the row estimate since 8f29467c57f

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: shihao zhong <zhong950419(at)gmail(dot)com>
Cc: alpkeles99(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: BUG #19759: Hashed SetOp / RecursiveUnion pre-allocate up to 64 GB from the row estimate since 8f29467c57f
Date: 2026-10-27 20:11:18
Message-ID: CAApHDvq6Ut5kVZYKT9PtyXmYB652vRn4fPSAtem80QBTZ_HCWA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Thanks for the review.

On Sat, 24 Oct 2026 at 17:48, shihao zhong <zhong950419(at)gmail(dot)com> wrote:
> The patch fixes the cases from the report for me. Two small things.
>
> 1. simplehash rounds the size up to a power of 2, so the empty table
> can still be twice hash_mem. With work_mem = 1GB, a plain EXPLAIN of
> the recursive query zeroes 4 GB. Halving the limit fixes it.
> hash_choose_num_buckets() does the same.

While it is true that simplehash will make the bucket count the next
power of 2 value, I didn't do this as I wanted to restore what we did
prior to 8f29467c5 in terms of the hard limit.

> 2. Plain EXPLAIN still builds the table. nodeAgg skips it.

Seems unrelated and I don't recall anyone complaining. Not something I
think we should adjust last minute before v19 goes out the door.

Now pushed.

David

In response to

Browse pgsql-bugs by date

  From Date Subject
Previous Message Manu 2026-10-27 20:03:26 Re: BUG #19760: CLUSTER loses a row the transaction inserted and then updated in a rolled-back subtransaction