| From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
|---|---|
| To: | Artem Tomyuk <admin(at)leboutique(dot)com> |
| Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: HASH |
| Date: | 2015-11-05 11:24:24 |
| Message-ID: | CAMkU=1x=if-tO1CkoVPqLnWxz8nYtu4Gs3JBw5ceLxFgVwwfkg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Thu, Nov 5, 2015 at 1:11 AM, Artem Tomyuk <admin(at)leboutique(dot)com> wrote:
> Hi all.
>
> Is the speed of hash operations stands on the performance of CPU?
Yes, but the variation is probably not as much as the raw timing in
your example indicates.
> Below you can see part from output of explain analyze command
>
> Intel(R) Xeon(R) CPU E7520 @ 1.87GHz
>
> " -> Hash (cost=337389.43..337389.43 rows=3224443 width=34)
> (actual time=15046.382..15046.382 rows=3225191 loops=1)"
> " Buckets: 524288 Batches: 1 Memory Usage: 207874kB"
A lot of that time was probably spent reading the data off of disk so
that it could hash it.
You should turn track_io_timing on, run "explain (analyze, buffers)
..." and then show the entire explain output, or at least also show
the entries downstream of the Hash node.
Cheers,
Jeff
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joe Van Dyk | 2015-11-07 23:31:18 | querying jsonb for arrays inside a hash |
| Previous Message | Evgeniy Shishkin | 2015-11-05 09:45:31 | Re: Yet another abort-early plan disaster on 9.3 |