Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id 1BB74A5CB37 for ; Wed, 15 Feb 2012 06:55:34 -0400 (AST) Received: from mail.anarazel.de ([217.115.131.40]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1RxcWL-0000cg-Pf for pgsql-performance@postgresql.org; Wed, 15 Feb 2012 10:55:34 +0000 Received: from intern.anarazel.de (p57A9EC32.dip.t-dialin.net [87.169.236.50]) (Authenticated sender: andres@anarazel.de) by mail.anarazel.de (Postfix) with ESMTPA id 2948C448005; Wed, 15 Feb 2012 11:55:20 +0100 (CET) From: Andres Freund To: pgsql-performance@postgresql.org Subject: Re: Fwd: [HACKERS] client performance v.s. server statistics Date: Wed, 15 Feb 2012 11:55:19 +0100 User-Agent: KMail/1.13.7 (Linux/3.1.0-1-amd64; KDE/4.6.5; x86_64; ; ) Cc: Zhou Han References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201202151155.19449.andres@anarazel.de> X-Pg-Spam-Score: -2.6 (--) X-Archive-Number: 201202/115 X-Sequence-Number: 46287 Hi, On Wednesday, February 15, 2012 11:19:00 AM Zhou Han wrote: > I have tried unix domain socket and the performance is similar with > TCP socket. It is MIPS architecture so memory copy to/from kernel can > occupy much time, and apparently using unit domain socket has no > difference than TCP in terms of memory copy. > But it is still unbelievable for the ten-fold gap between the client > side statistic and the server side statistics. So I want to know what > exactly the operations are involved in the server side statistics in > EXPLAIN ANALYZE. May I check the code later on when I get time. My guess is that the time difference youre seing is actually the planning time. The timing shown at the end of EXPLAIN ANALYZE is just the execution, not the planning time. You can use "\timing on" in psql to let it display timing information that include planning. Whats the query? > For the query itself, it was just for performance comparison. There > are other index based queries, which are of course much faster, but > still result in similar ten-fold of time gap between client side and > server side statistics. > > I am thinking of non-kernel involved client interface, is there such > an option, or do I have to develop one from scratch? Its unlikely thats possible in a sensible amount of time. But I don't think thats your problem anyway. Andres