X-Original-To: pgsql-performance-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id C5C309FA465 for ; Tue, 12 Sep 2006 13:52:17 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 65250-07 for ; Tue, 12 Sep 2006 13:52:09 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id A447A9FA432 for ; Tue, 12 Sep 2006 13:52:08 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id k8CGq6pS017035; Tue, 12 Sep 2006 12:52:06 -0400 (EDT) To: Laszlo Nagy cc: pgsql-performance@postgresql.org Subject: Re: Poor performance on seq scan In-reply-to: <450684EC.4090304@designaproduct.biz> References: <450684EC.4090304@designaproduct.biz> Comments: In-reply-to Laszlo Nagy message dated "Tue, 12 Sep 2006 11:59:08 +0200" Date: Tue, 12 Sep 2006 12:52:06 -0400 Message-ID: <17034.1158079926@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=1.115 tagged_above=0 required=5 tests=AWL, BIZ_TLD, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * X-Archive-Number: 200609/93 X-Sequence-Number: 20779 Laszlo Nagy writes: > Meanwhile, "iostat 5" gives something like this: > tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id > 1 14 128.00 1 0.10 128.00 1 0.10 5 0 94 1 0 > 0 12 123.98 104 12.56 123.74 104 12.56 8 0 90 2 0 > 0 12 125.66 128 15.75 125.26 128 15.68 10 0 85 6 0 > 0 12 124.66 129 15.67 124.39 129 15.64 12 0 85 3 0 > 0 12 117.13 121 13.87 117.95 121 13.96 12 0 84 5 0 > 0 12 104.84 118 12.05 105.84 118 12.19 10 0 87 2 0 Why is that showing 85+ percent *system* CPU time?? I could believe a lot of idle CPU if the query is I/O bound, or a lot of user time if PG was being a hog about doing the ~~ comparisons (not too unlikely BTW). But if the kernel is eating all the CPU, there's something very wrong, and I don't think it's Postgres' fault. regards, tom lane