Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ZX8UG-0008Q5-8b for pgsql-hackers@arkaria.postgresql.org; Wed, 02 Sep 2015 13:54:04 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ZX8UF-0002MN-BY for pgsql-hackers@arkaria.postgresql.org; Wed, 02 Sep 2015 13:54:03 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1ZX8UD-0002ME-RM for pgsql-hackers@postgresql.org; Wed, 02 Sep 2015 13:54:01 +0000 Received: from mail.anarazel.de ([217.115.131.40]) by magus.postgresql.org with esmtp (Exim 4.84) (envelope-from ) id 1ZX8U6-000887-Dr for pgsql-hackers@postgresql.org; Wed, 02 Sep 2015 13:54:01 +0000 Received: from intern.anarazel.de (ns1.anarazel.de [217.115.131.41]) (Authenticated sender: andres@anarazel.de) by mail.anarazel.de (Postfix) with ESMTPSA id 6EE7F860001; Wed, 2 Sep 2015 15:53:53 +0200 (CEST) Date: Wed, 2 Sep 2015 15:53:51 +0200 From: Andres Freund To: Julien Rouhaud Cc: Jeff Janes , Bruce Momjian , Merlin Moncure , "pgsql-hackers@postgresql.org" Subject: Re: Allow a per-tablespace effective_io_concurrency setting Message-ID: <20150902135351.GA5286@alap3.anarazel.de> References: <20141206130828.GA1314@momjian.us> <20141209204337.GC24488@momjian.us> <55AA2469.20306@dalibo.com> <55AA27C3.7060009@dalibo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55AA27C3.7060009@dalibo.com> X-Pg-Spam-Score: -4.2 (----) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Hi, On 2015-07-18 12:17:39 +0200, Julien Rouhaud wrote: > I didn't know that the thread must exists on -hackers to be able to add > a commitfest entry, so I transfer the thread here. Please, in the future, also update the title of the thread to something fitting. > @@ -539,6 +541,9 @@ ExecInitBitmapHeapScan(BitmapHeapScan *node, EState *estate, int eflags) > { > BitmapHeapScanState *scanstate; > Relation currentRelation; > +#ifdef USE_PREFETCH > + int new_io_concurrency; > +#endif > > /* check for unsupported flags */ > Assert(!(eflags & (EXEC_FLAG_BACKWARD | EXEC_FLAG_MARK))); > @@ -598,6 +603,25 @@ ExecInitBitmapHeapScan(BitmapHeapScan *node, EState *estate, int eflags) > */ > currentRelation = ExecOpenScanRelation(estate, node->scan.scanrelid, eflags); > > +#ifdef USE_PREFETCH > + /* check if the effective_io_concurrency has been overloaded for the > + * tablespace storing the relation and compute the target_prefetch_pages, > + * or just get the current target_prefetch_pages > + */ > + new_io_concurrency = get_tablespace_io_concurrency( > + currentRelation->rd_rel->reltablespace); > + > + > + scanstate->target_prefetch_pages = target_prefetch_pages; > + > + if (new_io_concurrency != effective_io_concurrency) > + { > + double prefetch_pages; > + if (compute_io_concurrency(new_io_concurrency, &prefetch_pages)) > + scanstate->target_prefetch_pages = rint(prefetch_pages); > + } > +#endif Maybe it's just me - but imo there should be as few USE_PREFETCH dependant places in the code as possible. It'll just be 0 when not supported, that's fine? Especially changing the size of externally visible structs depending on a configure detected ifdef seems wrong to me. > +bool > +compute_io_concurrency(int io_concurrency, double *target_prefetch_pages) > +{ > + double new_prefetch_pages = 0.0; > + int i; > + > + /* make sure the io_concurrency value is correct, it may have been forced > + * with a pg_tablespace UPDATE > + */ Nitpick: Wrong comment style (/* stands on its own line). > + if (io_concurrency > MAX_IO_CONCURRENCY) > + io_concurrency = MAX_IO_CONCURRENCY; > + > + /*---------- > + * The user-visible GUC parameter is the number of drives (spindles), > + * which we need to translate to a number-of-pages-to-prefetch target. > + * The target value is stashed in *extra and then assigned to the actual > + * variable by assign_effective_io_concurrency. > + * > + * The expected number of prefetch pages needed to keep N drives busy is: > + * > + * drives | I/O requests > + * -------+---------------- > + * 1 | 1 > + * 2 | 2/1 + 2/2 = 3 > + * 3 | 3/1 + 3/2 + 3/3 = 5 1/2 > + * 4 | 4/1 + 4/2 + 4/3 + 4/4 = 8 1/3 > + * n | n * H(n) I know you just moved this code. But: I don't buy this formula. Like at all. Doesn't queuing and reordering entirely invalidate the logic here? Perhaps more relevantly: Imo nodeBitmapHeapscan.c is the wrong place for this. bufmgr.c maybe? You also didn't touch /* * How many buffers PrefetchBuffer callers should try to stay ahead of their * ReadBuffer calls by. This is maintained by the assign hook for * effective_io_concurrency. Zero means "never prefetch". */ int target_prefetch_pages = 0; which surely doesn't make sense anymore after these changes. But do we even need that variable now? > diff --git a/src/include/utils/guc.h b/src/include/utils/guc.h > index dc167f9..57008fc 100644 > --- a/src/include/utils/guc.h > +++ b/src/include/utils/guc.h > @@ -26,6 +26,9 @@ > #define MAX_KILOBYTES (INT_MAX / 1024) > #endif > > +/* upper limit for effective_io_concurrency */ > +#define MAX_IO_CONCURRENCY 1000 > + > /* > * Automatic configuration file name for ALTER SYSTEM. > * This file will be used to store values of configuration parameters > @@ -256,6 +259,8 @@ extern int temp_file_limit; > > extern int num_temp_buffers; > > +extern int effective_io_concurrency; > + target_prefetch_pages is declared in bufmgr.h - that seems like a better place for these. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers