Skip site navigation (1) Skip section navigation (2)

Re: Inefficient bytea escaping?

From: Thomas Hallgren <thomas(at)tada(dot)se>
To: Marko Kreen <markokr(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Andreas Pflug <pgadmin(at)pse-consulting(dot)de>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Inefficient bytea escaping?
Date: 2006-05-29 06:01:07
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Marko Kreen wrote:
> On 5/28/06, Martijn van Oosterhout <kleptog(at)svana(dot)org> wrote:
>> With -lpthread
>> lock.enabled     323s
>> lock.disabled     50s
>> lock.unlocked     36s
> I forgot to test with -lpthread, my bad.  Indeed by default
> something less expensive that full locking is going on.
>> The crux of the matter is though, if you're calling something a million
>> times, you're better off trying to find an alternative anyway. There is
>> a certain amount of overhead to calling shared libraries and no amount
>> of optimisation of the library is going save you that.
> The crux of the matter was if its possible to use fwrite
> as easy string combining mechanism and the answer is no,
> because it's not lightweight enough.
IIRC the windows port make use of multi-threading to simulate signals and it's likely that 
some add-on modules will bring in libs like pthread. It would be less ideal if PostgreSQL 
was designed to take a significant performance hit when that happens. Especially if a viable 
alternative exists.

Thomas Hallgren

In response to

pgsql-hackers by date

Next:From: Martijn van OosterhoutDate: 2006-05-29 06:52:13
Subject: Re: LIKE, leading percent, bind parameters and indexes
Previous:From: PFCDate: 2006-05-29 05:10:03
Subject: Re: pg_proc probin misuse

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group