Re: Hash join gets slower as work_mem increases?

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>, Schwarzinger Andreas <andreas(dot)schwarzinger(at)wien(dot)gv(dot)at>
Subject: Re: Hash join gets slower as work_mem increases?
Date: 2016-01-29 15:21:41
Message-ID: CAFj8pRDTiqpipB1jP2w3euUe2RfYwhp96g_3yPT=UKeCMDkobg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Hi

> I ran operf on both backends, and they look quite similar, except that the
> number of samples is different (this is "opreport -c" output):
>
> CPU: Intel Sandy Bridge microarchitecture, speed 2899.8 MHz (estimated)
> Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit
> mask of 0x00 (No unit mask) count 90000
> samples % image name symbol name
>
> -------------------------------------------------------------------------------
> 112 0.0019 postgres ExecProcNode
> 3020116 49.9904 postgres ExecScanHashBucket
> 3021162 50.0077 postgres ExecHashJoin
> 3020116 92.8440 postgres ExecScanHashBucket
> 3020116 49.9207 postgres ExecScanHashBucket [self]
> 3020116 49.9207 postgres ExecScanHashBucket
> 8190 0.1354 vmlinux apic_timer_interrupt
>
> What could be an explanation for this?
> Is this known behaviour?
>

one issue was fixed in 9.5

large hash table can introduce a lot of outs from L1, L2 caches.

Pavel

>
> Yours,
> Laurenz Albe
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message jfleming 2016-01-29 22:06:23 jsonb_agg performance
Previous Message Albe Laurenz 2016-01-29 15:17:49 Hash join gets slower as work_mem increases?