Re: why do we need two snapshots per query? - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: why do we need two snapshots per query?
Date
Msg-id 20111115.090610.1417035665252020145.t-ishii@sraoss.co.jp
Whole thread Raw
In response to Re: why do we need two snapshots per query?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
> On the other hand, if our goal in life is to promote the extended
> query protocol over the simple query protocol at all costs, then I
> agree that we shouldn't optimize the simple query protocol in any way.
>  Perhaps we should even post a big notice on it that says "this
> facility is deprecated and will be removed in a future version of
> PostgreSQL".  But why should that be our goal?  Presumably our goal is
> to put forward the best technology, not to artificially pump up one
> alternative at the expense of some other one.  If the simple protocol
> is faster in certain use cases than the extended protocol, then let
> people use it.  I wouldn't have noticed this optimization opportunity
> in the first place but for the fact that psql seems to use the simple
> protocol - why does it do that, if the extended protocol is
> universally better?  I suspect that, as with many other things where
> we support multiple alternatives, the best alternative depends on the
> situation, and we should let users pick depending on their use case.

+1. I don't see any justfication not to enhance simple protocol case
influenced by extended protocol's relatively poor performance.

> At any rate, if you're concerned about the relative efficiency of the
> simple query protocol versus the extended protocol, it seems that the
> horse has already left the barn.  I just did a quick 32-client pgbench
> -S test on a 32-core box.  This is just a thirty-second run, but
> that's enough to make the point: if you're not using prepared queries,
> using the extended query protocol incurs a significant penalty - more
> than 15% on this test:
> 
> [simple] tps = 246808.409932 (including connections establishing)
> [extended] tps = 205609.438247 (including connections establishing)
> [prepared] tps = 338150.881389 (including connections establishing)

Quite impressive result.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp


pgsql-hackers by date:

Previous
From: Josh Kupershmidt
Date:
Subject: psql + libedit command history truncation (was: psql history vs. dearmor (pgcrypto))
Next
From: Josh Berkus
Date:
Subject: Re: Core Extensions relocation