Re: When Update balloons memory - Mailing list pgsql-bugs

From Tom Lane
Subject Re: When Update balloons memory
Date
Msg-id 261065.1639497535@sss.pgh.pa.us
Whole thread Raw
Responses Re: When Update balloons memory  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-bugs
[ redirecting to pgsql-bugs ]

Klaudie Willis <Klaudie.Willis@protonmail.com> writes:
> 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(1, 30 * 1E6) as x;

> CREATE INDEX partindx ON public.part_main USING btree ((actiondate)::date);  -- mem bug?
> -- mem runaway follows
> update part_main set txid = txid + 1;

ITYM "((actiondate::date))", but yeah, this leaks memory like there's
no tomorrow.  I traced it to 9dc718bdf (Pass down "logically unchanged
index" hint), which has added a function index_unchanged_by_update()
that (a) looks fairly expensive, (b) leaks a copy of every expression
tree it examines, and (c) is invoked over again for each row, even
though AFAICS the answer shouldn't change across rows.  This seems very
poorly thought through.  Peter?

            regards, tom lane

PS: personally I would have used pull_varnos() instead of reinventing
that wheel.  But in any case the real problem is repeated invocation.



pgsql-bugs by date:

Previous
From: Dmitry Dolgov
Date:
Subject: Re: BUG #17326: Postgres crashed when pg_reload_conf() with ssl certificate parameters
Next
From: Tom Lane
Date:
Subject: Re: BUG #17336: logtape sort performance and overflow