| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Sergey Koposov <Sergey(dot)Koposov(at)ed(dot)ac(dot)uk> |
| Cc: | "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #18909: Query creates millions of temporary files and stalls |
| Date: | 2025-05-03 16:27:06 |
| Message-ID: | 2177960.1746289626@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Sergey Koposov <Sergey(dot)Koposov(at)ed(dot)ac(dot)uk> writes:
> #8 0x00005615d84f6a59 in ExecHashTableInsert (hashtable=0x5615da85e5c0, slot=0x5615da823378, hashvalue=2415356794)
> at nodeHash.c:1714
> shouldFree = true
> tuple = 0x5615da85f5e8
> bucketno = 32992122
> batchno = 3521863
Yeah, this confirms the idea that the hashtable has exploded into an
unreasonable number of buckets and batches. I don't know why a
parallel hash join would be more prone to do that than a non-parallel
one, though. I'm hoping some of the folks who worked on PHJ will
look at this.
What have you got work_mem set to? I hope it's fairly large, if
you need to join such large tables.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Abdullah DURSUN | 2025-05-03 16:50:00 | Planner does not use btree index for LIKE 'prefix%' on text column, but does for equivalent range query (PostgreSQL 17.4) |
| Previous Message | Sergey Koposov | 2025-05-03 16:11:35 | Re: BUG #18909: Query creates millions of temporary files and stalls |