From: | "Strong, David" <david(dot)strong(at)unisys(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Faster StrNCpy |
Date: | 2006-10-02 21:35:19 |
Message-ID: | B6419AF36AC8524082E1BC17DA2506E802579E2E@USMV-EXCH2.na.uis.unisys.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Tom,
Yes, the clients are using the V3 protocol and prepared statements.
David
________________________________
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Mon 10/2/2006 2:09 PM
To: Strong, David
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Faster StrNCpy
"Strong, David" <david(dot)strong(at)unisys(dot)com> writes:
> Obviously, different copy mechanisms suit different data sizes. So, I
> added a little debug to the strlcpy () function that was added to
> Postgres the other day. I ran a test against Postgres for ~15 minutes
> that used 2 client backends and the BG writer - 8330804 calls to
> strlcpy () were generated by the test.
> Out of the 8330804 calls, 6226616 calls used a maximum copy size of
> 2213 bytes e.g. strlcpy (dest, src, 2213) and 2104074 calls used a
> maximum copy size of 64 bytes.
> I know the 2213 size calls come from the set_ps_display () function. I
> don't know where the 64 size calls come from, yet.
Prepared-statement and portal hashtable lookups, likely. Were your
clients using V3 extended query protocol?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Radovan Jablonov | 2006-10-02 21:38:22 | on-disk bitmap indexes |
Previous Message | Tom Lane | 2006-10-02 21:09:16 | Re: Faster StrNCpy |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2006-10-02 22:32:13 | Re: minor editorial of tsearch2 readme |
Previous Message | Tom Lane | 2006-10-02 21:09:16 | Re: Faster StrNCpy |