X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 738A29FA4A0 for ; Mon, 1 May 2006 12:15:30 -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 58836-05 for ; Mon, 1 May 2006 12:15:24 -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 D2B0E9F9DCD for ; Mon, 1 May 2006 12:15:23 -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 k41FFJUv005883; Mon, 1 May 2006 11:15:19 -0400 (EDT) To: "Steve Woodcock" cc: "Scott Sipe" , pgsql-performance@postgresql.org Subject: Re: Super-smack? In-reply-to: References: <92F10BE1-B193-4EEA-877A-9260B55C2844@mindspring.com> Comments: In-reply-to "Steve Woodcock" message dated "Mon, 01 May 2006 14:06:44 +0100" Date: Mon, 01 May 2006 11:15:19 -0400 Message-ID: <5882.1146496519@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200605/5 X-Sequence-Number: 18792 "Steve Woodcock" writes: > On 01/05/06, Scott Sipe wrote: >> So, my question is, before I do any further digging, is super-smack >> flawed? > Hmm, selects and updates of a 90k row table using the primary key, but > no sign of a VACUUM ANALYZE... Reasonably recent versions of PG should be able to do "the right thing" in the presence of a simple primary key, even without any prior ANALYZE; the planner will see the unique index and make the right conclusions about statistics. If the test is doing a huge number of UPDATEs and no VACUUM anywhere, then accumulation of dead rows would eventually hurt, but it's not clear from Scott's report if that's the issue. I'm inclined to think there's some more subtle bias in the testbed. I haven't dug into the code to look at how they are managing multiple connections, but I wonder if say there's something causing the client to not notice responses from the server right away when it's going through libpq. FWIW, my own experiments with tests like this suggest that PG is at worst about 2x slower than mysql for trivial queries. If you'd reported a result in that ballpark I'd have accepted it as probably real. 6x I don't believe though ... regards, tom lane