Timeline for Why does adding a smallint column to a postgres query increase execution time 60X?
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 14, 2016 at 6:18 | comment | added | jjanes | @J-16SDiZ Unfortunately we can't try it out for ourselves, as we don't have access to the OP's data. This is a data-dependent problem. | |
| Jan 12, 2016 at 5:28 | comment | added | J-16 SDiZ |
If you want a solid proof, do an explain (analyze,buffers) and you will see what i am saying.
|
|
| Jan 12, 2016 at 5:25 | comment | added | J-16 SDiZ |
@dezso yes, but the large batch number shows they don't fit in memory (and have written to temp files). Retrieving them from disk for hash join step is slow. Why not give it a try and see? Changing work_mem is trivial -- it is a session configurable.
|
|
| Jan 11, 2016 at 20:34 | comment | added | jjanes | @dezso The Hash Right Join node must operate on the number of batches set up for it by the Hash node. So where the problem manifests is one place, but where the problem is caused is the other place. Also, while I agree that adding one smallint column should not cause this particular change, I think the evidence speaks for itself. | |
| Jan 8, 2016 at 13:36 | comment | added | András Váczi | This hash is only slightly slower than the fast one (well, about double the time, but it's only 50 ms). The real difference shows itself in the Hash Right Join node - also, one smallint in the 10+ column list cannot cause such a big change, in my view. | |
| Jan 8, 2016 at 6:41 | history | answered | J-16 SDiZ | CC BY-SA 3.0 |