Re: Scanner performance (was Re: 7.3 schedule)

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Ashley Cambrell <ash(at)freaky-namuh(dot)com>, Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Scanner performance (was Re: 7.3 schedule)
Date: 2002-04-16 17:55:41
Message-ID: 200204161755.g3GHtfO19314@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut wrote:
> The string literals didn't contain any backslashes, so scanstr is
> operating in the best-case scenario here. But for arbitary binary data we
> need some escape mechanism, so I don't see much room for improvement
> there.
>
> It seems the real bottleneck is the excessive abstraction in the
> communications layer. I haven't looked closely at all, but it would seem
> better if pq_getstring would not use pq_getbyte and instead read the
> buffer directly.

I am inclined to agree with your analysis. We added abstraction to
libpq because the old code was quite poorly structured. Now that it is
well structured, removing some of the abstraction seems valuable.

Any chance pq_getbyte could be made into a macro? I would be glad to
send you a macro version for testing. I would have to push the while
loop into pg_recvbuf() and change the while in pg_getbyte to an if, or
as a macro, ? :.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 2002-04-16 18:06:01 Re: Testers needed ...
Previous Message Peter Eisentraut 2002-04-16 17:24:12 Re: Scanner performance (was Re: 7.3 schedule)