X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id B3253D9CAD for ; Fri, 30 Sep 2005 17:37:56 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 87975-01 for ; Fri, 30 Sep 2005 20:37:53 +0000 (GMT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by svr1.postgresql.org (Postfix) with ESMTP id 5F335D9CA2 for ; Fri, 30 Sep 2005 17:37:53 -0300 (ADT) Received: from phys-bur-1 ([129.148.9.72]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j8UKbs1P025267 for ; Fri, 30 Sep 2005 14:37:55 -0600 (MDT) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0INN00G01D5LGM@bur-mail1.east.sun.com> (original mail from J.K.Shah@Sun.COM) for pgsql-hackers@postgresql.org; Fri, 30 Sep 2005 16:37:54 -0400 (EDT) Received: from [129.150.35.4] (vpn-129-150-35-4.Central.Sun.COM [129.150.35.4]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0INN00F97DB481@bur-mail1.east.sun.com>; Fri, 30 Sep 2005 16:37:54 -0400 (EDT) Date: Fri, 30 Sep 2005 16:38:00 -0400 From: "Jignesh K. Shah" Subject: Re: [PERFORM] A Better External Sort? In-reply-to: <31833713.1128111650174.JavaMail.root@elwamui-polski.atl.sa.earthlink.net> To: Ron Peacetree Cc: Josh Berkus , pgsql-hackers@postgresql.org, pgsql-performance@postgresql.org Message-id: <433DA228.4060103@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) References: <31833713.1128111650174.JavaMail.root@elwamui-polski.atl.sa.earthlink.net> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0 required=5 tests=[none] X-Spam-Level: X-Archive-Number: 200509/1442 X-Sequence-Number: 73839 I have seen similar performance as Josh and my reasoning is as follows: * WAL is the biggest bottleneck with its default size of 16MB. Many people hate to recompile the code to change its default, and increasing checkpoint segments help but still there is lot of overhead in the rotation of WAL files (Even putting WAL on tmpfs shows that it is still slow). Having an option for bigger size is helpful to a small extent percentagewise (and frees up CPU a bit in doing file rotation) * Growing files: Even though this is OS dependent but it does spend lot of time doing small 8K block increases to grow files. If we can signal bigger chunks to grow or "pre-grow" to expected size of data files that will help a lot in such cases. * COPY command had restriction but that has been fixed to a large extent.(Great job) But ofcourse I have lost touch with programming and can't begin to understand PostgreSQL code to change it myself. Regards, Jignesh Ron Peacetree wrote: >That 11MBps was your =bulk load= speed. If just loading a table >is this slow, then there are issues with basic physical IO, not just >IO during sort operations. > >As I said, the obvious candidates are inefficient physical layout >and/or flawed IO code. > >Until the basic IO issues are addressed, we could replace the >present sorting code with infinitely fast sorting code and we'd >still be scrod performance wise. > >So why does basic IO suck so badly? > >Ron > > >-----Original Message----- >From: Josh Berkus >Sent: Sep 30, 2005 1:23 PM >To: Ron Peacetree >Cc: pgsql-hackers@postgresql.org, pgsql-performance@postgresql.org >Subject: Re: [HACKERS] [PERFORM] A Better External Sort? > >Ron, > > > >>Hmmm. >>60GB/5400secs= 11MBps. That's ssllooww. So the first >>problem is evidently our physical layout and/or HD IO layer >>sucks. >> >> > >Actually, it's much worse than that, because the sort is only dealing >with one column. As I said, monitoring the iostat our top speed was >2.2mb/s. > >--Josh > > >---------------------------(end of broadcast)--------------------------- >TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > >