| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru> |
| Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, 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-09 19:04:41 |
| Message-ID: | 20210509190441.6wcxpp5543hg5oqz@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2021-05-09 15:57:22 +0300, Yura Sokolov wrote:
> Occasionally there is a need to run cassert builds in production to
> catch an issue. It is usually ok if cassert build O(1) slower than
> optimized biuld (ie it is slower in some constant factor C). But
> if cassert build will be quadratically slower, it will unusable.
The memory context assertion overhead is more than O(1) expensive. I
think there's plenty other cases like it. We removed some (e.g. it used
to be that we scanned O(#shared_buffers) entries in the local pin table,
at the end of the transaction). I don't think we want to limit ourselves
to O(1) checks. That's not to say we should have a O(n^2) or such,
unless we have confidence n rarely will be big.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-05-09 19:29:06 | Non-reproducible valgrind failure on HEAD |
| Previous Message | Andres Freund | 2021-05-09 18:55:04 | Re: [PATCH] Identify LWLocks in tracepoints |