From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Heinemann, Manfred (IMS)" <HeinemannM(at)imsweb(dot)com> |
Cc: | "pgsql-admin(at)lists(dot)postgresql(dot)org" <pgsql-admin(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Function search_path |
Date: | 2018-03-25 17:13:31 |
Message-ID: | 11207.1521998011@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
"Heinemann, Manfred (IMS)" <HeinemannM(at)imsweb(dot)com> writes:
> Here is an example where I can show significant extra memory consumption when setting search_path on a function:
I got around to testing this example today, and I don't see what you're
seeing --- the memory consumption seems stable, and about the same with
or without the "SET search_path" clause.
You didn't specify exactly how to do this bit:
--populate 1,000,000 rows with random values from 1,000 surnames for 'SURNAME'
so I did it like this:
INSERT INTO test_search_path(date_last_modified, last_name)
select clock_timestamp(), (random()*1000)::int::text
from generate_series(1,1000000);
The example doesn't seem like it'd be terribly data-dependent, but
maybe that's wrong?
Also, I assume you're running a reasonably up-to-date PG release,
otherwise I'd be wondering about leaks in the GIN index AM; we've
fixed some issues of that sort in GIN bulk updates in the past.
But again, it's not clear what the connection to a function SET
clause would be. So I lack a plausible theory at the moment.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Thrikal Samy | 2018-03-26 10:37:28 | BDR support for postgres 10 |
Previous Message | Laurenz Albe | 2018-03-25 04:34:01 | Re: bloatcheck.sql |