Re: When Update balloons memory

[ redirecting to pgsql-bugs ]

Klaudie Willis <Klaudie(dot)Willis(at)protonmail(dot)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.