Re: Pl/Perl function: Speed of the First time executing pl/perl function in connection;

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Oleg Serov <serovov(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Pl/Perl function: Speed of the First time executing pl/perl function in connection;
Date: 2008-11-17 17:22:09
Message-ID: 4648.1226942529@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Tom Lane wrote:
>> The point here is to do the work at postmaster start time. You won't
>> get a chance to find out whether both languages are defined in some
>> database or other. (This is the same thing as the point about the
>> UTF8 hack --- you can't tell if it's needed or not.)

> w.r.t. UTF8, I guess we'll need a way of knowing if we're preloading or
> not, and if so we'd need to skip the calls to GetDatabaseEncoding().

If you mean that you want to still do the UTF8 hack at backend start
time, I think you might as well not bother with any of this. That hack
in itself is slow enough to be 50% of the problem (presumably because
it's loading some modules down in there somewhere). We need to arrange
to either not do it at all or do it at preload.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2008-11-17 17:31:16 Re: Pl/Perl function: Speed of the First time executing pl/perl function in connection;
Previous Message Simon Riggs 2008-11-17 17:10:32 Re: Synchronous replication patch v2