From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: plan with result cache is very slow when work_mem is not enough |
Date: | 2021-05-07 19:18:11 |
Message-ID: | CAFj8pRCmK5xe-WM0aqb9vY1KHD1ZdiiEjmrXjtaJ0WOE8_EnOg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
pá 7. 5. 2021 v 21:06 odesílatel Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>
napsal:
> Pavel Stehule писал 2021-05-07 21:45:
> >>
> >> Samples: 119K of event 'cycles', 4000 Hz, Event count (approx.):
> >> Overhead Shared Object Symbol
> >> 79.20% postgres [.] cache_reduce_memory
> >> 1.94% [kernel] [k] native_write_msr_safe
> >> 1.63% [kernel] [k] update_cfs_shares
> >> 1.00% [kernel] [k] trigger_load_balance
> >> 0.97% [kernel] [k] timerqueue_add
> >> 0.51% [kernel] [k] task_tick_fair
> >> 0.51% [kernel] [k] task_cputime
> >> 0.50% [kernel] [k] perf_event_task_tick
> >> 0.50% [kernel] [k] update_curr
> >> 0.49% [kernel] [k] hrtimer_active
> >>
> >> Regards
> >>
> >> Pavel
>
> It is strange to see cache_reduce_memory itself consumes a lot of CPU.
> It doesn't contain CPU hungry code.
> It calls prepare_probe_slot, that calls some tuple forming. Then
> it calls resultcache_lookup that may call to ResultCacheHash_hash
> and ResultCacheHash_equal. And finally it calls remove_cache_entry.
> I suppose remove_cache_entry should consume most of CPU time since
> it does deallocations.
> And if you compile with --enable-cassert, then remove_cache_entry
> iterates through whole cache hashtable, therefore it reaches
> quadratic complexity easily (or more correct M*N, where M - size
> of a table, N - eviction count).
>
yes, the slowdown is related to debug assertions
Pavel
> regards,
> Yura Sokolov
>
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2021-05-07 19:23:34 | Re: Draft back-branch release notes are up |
Previous Message | Tomas Vondra | 2021-05-07 19:17:30 | Re: plan with result cache is very slow when work_mem is not enough |