Re: Function search_path

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

In response to

Responses

Browse pgsql-admin by date

  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