On Tue, 14 Dec 2021 11:18:07 -0500
Tom Lane wrote:
>
> This leak is new in v14, possibly that's why Vincent didn't reproduce it.
Indeed, I'm on v11
--
Bien à vous, Vincent Veyron
https://marica.fr
Gestion des contentieux juridiques, des contrats et
Klaudie Willis writes:
> I'll repost it here, corrected, for others to use who wants to exhaust their
> memory:
> --PG-14.1
This leak is new in v14, possibly that's why Vincent didn't reproduce it.
regards, tom lane
So sorry about that;
I'll repost it here, corrected, for others to use who wants to exhaust their
memory:
--PG-14.1
CREATE TABLE public.part_main (
txid bigint,
actiondate timestamp without time zone NOT NULL
);
insert into part_main
select x, '2019-06-01'::timestamp + x%365 * interval
On Tue, 14 Dec 2021 08:16:08 +
Klaudie Willis wrote:
> CREATE INDEX partindx ON public.part_main USING btree ((actiondate)::date);
> -- mem bug?
Nope, syntax error
ERROR: syntax error at or near "::"
LINE 1: ...indx_1 ON public.part_main USING btree ((actiondate)::date);
Hi,
Turns out the base case is simpler than I thought. Not involving partitions at
all
CREATE TABLE public.part_main (
txid bigint,
actiondate timestamp without time zone NOT NULL
);
insert into part_main
select x, '2019-06-01'::timestamp + x%365 * interval '1 day'
from generate_series(
Klaudie Willis writes:
> So, it seems like the index is central cog here:
>> create index ind1 on alpha ((deltatime::date));
> where "alpha" is a partition tableset partitioned by (deltatime::date)
> The general and simple updates like:
>> update alphatable set gamma=gamma || "#postfix#"
> makes t
Thanks for the insight!
I have recreated the problem on a different machine and installation where I
was more free to experiment to isolate what causes this.
So, it seems like the index is central cog here:
> create index ind1 on alpha ((deltatime::date));
where "alpha" is a partition tableset pa
Klaudie Willis writes:
> The following statement below, when not divided up into chunks, but run
> across all 800M rows, did trigger an OOM-kill from the OS.
An UPDATE should only result in memory bloat if it's queuing trigger
events to be processed at end-of-statement. You claim there are
no t
This has no solution for the issue but...
On Tue, 7 Dec 2021 at 10:16, Klaudie Willis
wrote:
> Ubuntu 20.04, 64GB ram, 16GB shared buffer, 500 MB working mem, Postgresql
> 14.1
...
> shared_buffers = 16GB
> effective_cache_size = 48GB
... You are not going to have total ram - shared buffers in t
