Re: [PERFORM] Hash Anti Join performance degradation
Cédric Villemain <cedric.villemain.debian@gmail.com>
From: Cédric Villemain <cedric.villemain.debian@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, panam <panam@gmx.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-06-01T20:34:38Z
Lists: pgsql-hackers, pgsql-performance
Attachments
- fix_hardtokill_hashv2.patch (text/x-patch) patch
2011/6/1 Tom Lane <tgl@sss.pgh.pa.us>: > We do need to look into putting a CHECK_FOR_INTERRUPTS call in here > somewhere, though. I'm inclined to think that right before the > ExecScanHashBucket is the best place. The reason that nest and merge > joins don't show a comparable non-responsiveness to cancels is that they > always call a child plan node at the equivalent place, and ExecProcNode > has got a CHECK_FOR_INTERRUPTS. So we ought to check for interrupts > at the point of "fetching a tuple from the inner child plan", and > ExecScanHashBucket is the equivalent thing in this logic. Cedric's > suggestion of putting it before the switch would get the job done, but > it would result in wasting cycles during unimportant transitions from > one state machine state to another. exact, thanks to your last email I read more the code and get the same conclusion and put it in a more appropriate place : before ExecScanHashBucket. I was about sending it, so it is attached. > > regards, tom lane > -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support