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
>
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? |