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

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

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: Mon, 29 May 2006 08:01:07 +0200
  • Message-id: <447A8E23(dot)2040108(at)tada(dot)se>

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.

Regards,
Thomas Hallgren




Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group