Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h4S1d-0005GR-GS for pgsql-performance@arkaria.postgresql.org; Thu, 14 Mar 2019 15:12:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1h4S1b-0004WB-Me for pgsql-performance@arkaria.postgresql.org; Thu, 14 Mar 2019 15:12:03 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h4S13-0008WM-I7 for pgsql-performance@lists.postgresql.org; Thu, 14 Mar 2019 15:11:29 +0000 Received: from smtp-fw-33001.amazon.com ([207.171.190.10]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h4S10-0002ak-Sc for pgsql-performance@lists.postgresql.org; Thu, 14 Mar 2019 15:11:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1552576286; x=1584112286; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=DQttpCeZDVC/CFxs+cjv/Ru9kvkJ7GnMUPjkwna32FI=; b=kID2CACejbWpqrAnDFRBGv4qihv586z40SUsTQfJMksTrdZkPNuIKvRR KClaG9KG+PpxQwFzc1bz/f3B0h6+RkyjUggeiZHZ+POyK8IAb6wWe9VtQ 4BqA+4UfPh9Sk6re3NtdiSWOrxJSiIpe5UBGzpgAWAtVMc9Ty7+IKukm+ M=; X-IronPort-AV: E=Sophos;i="5.58,478,1544486400"; d="scan'208";a="788609893" Received: from sea3-co-svc-lb6-vlan2.sea.amazon.com (HELO email-inbound-relay-1d-2c665b5d.us-east-1.amazon.com) ([10.47.22.34]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Mar 2019 15:11:22 +0000 Received: from EX13MTAUWA001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1d-2c665b5d.us-east-1.amazon.com (8.14.7/8.14.7) with ESMTP id x2EFBJ3F062823 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Mar 2019 15:11:21 GMT Received: from EX13D18UWA002.ant.amazon.com (10.43.160.199) by EX13MTAUWA001.ant.amazon.com (10.43.160.118) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 14 Mar 2019 15:11:21 +0000 Received: from 186590ce269b.ant.amazon.com (10.43.162.34) by EX13D18UWA002.ant.amazon.com (10.43.160.199) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 14 Mar 2019 15:11:21 +0000 Subject: Re: Distributing data over "spindles" even on AWS EBS, (followup to the work queue saga) To: Gunther , References: <679375f7-bb61-6a66-e91a-4b5454f9223b@gusw.net> From: Jeremy Schneider Message-ID: Date: Thu, 14 Mar 2019 08:11:20 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 In-Reply-To: <679375f7-bb61-6a66-e91a-4b5454f9223b@gusw.net> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.43.162.34] X-ClientProxiedBy: EX13D20UWC003.ant.amazon.com (10.43.162.18) To EX13D18UWA002.ant.amazon.com (10.43.160.199) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 3/14/19 07:53, Gunther wrote: > 2. build a low level "spreading" scheme which is to take the partial > files 4653828 and 4653828.1, .2, _fsm, etc. and move each to another > device and then symlink it back to that directory (I come back to this!) ... > To 2. I find that it would be a nice feature of PostgreSQL if we could > just use symlinks and a symlink rule, for example, when PostgreSQL finds > that 4653828 is in fact a symlink to /otherdisk/PG/16284/4653828, then > it would > > * by default also create 4653828.1 as a symlink and place the actual > data file on /otherdisk/PG/16284/4653828.1 How about if we could just specify multiple tablespaces for an object, and then PostgreSQL would round-robin new segments across the presently configured tablespaces? This seems like a simple and elegant solution to me. > 4. maybe I can configure in AWS EBS to reserve more IOPS -- but why > would I pay for more IOPS if my cost is by volume size? I can just > make another volume? or does AWS play a similar trick on us with > IOPS being limited on some "credit" system??? Not credits, but if you're using gp2 volumes then pay close attention to how burst balance works. A single large volume is the same price as two striped volumes at half size -- but the striped volumes will have double the burst speed and take twice as long to refill the burst balance. -Jeremy -- Jeremy Schneider Database Engineer Amazon Web Services