Re: [PERFORM] Hash Anti Join performance degradation

From: Cédric Villemain <cedric(dot)villemain(dot)debian(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, panam <panam(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PERFORM] Hash Anti Join performance degradation
Date: 2011-06-01 20:34:38
Message-ID: BANLkTi=Bn=ZiZrEWZmFNiTMCbjB=53j3Ew@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

2011/6/1 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

Attachment Content-Type Size
fix_hardtokill_hashv2.patch text/x-patch 1.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-06-01 20:35:16 Re: [PERFORM] Hash Anti Join performance degradation
Previous Message Tom Lane 2011-06-01 20:33:02 Re: [BUGS] BUG #6034: pg_upgrade fails when it should not.

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2011-06-01 20:35:16 Re: [PERFORM] Hash Anti Join performance degradation
Previous Message Robert Haas 2011-06-01 20:31:34 Re: [PERFORM] Hash Anti Join performance degradation