Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1euN6d-0001uk-7K for pgsql-hackers@arkaria.postgresql.org; Fri, 09 Mar 2018 18:51:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1euN6b-0005MZ-Vh for pgsql-hackers@arkaria.postgresql.org; Fri, 09 Mar 2018 18:51:01 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1euN6b-0005MN-Lg for pgsql-hackers@lists.postgresql.org; Fri, 09 Mar 2018 18:51:01 +0000 Received: from mail-qt0-f195.google.com ([209.85.216.195]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1euN6X-0002aR-OP for pgsql-hackers@postgresql.org; Fri, 09 Mar 2018 18:51:00 +0000 Received: by mail-qt0-f195.google.com with SMTP id a23so493362qtm.4 for ; Fri, 09 Mar 2018 10:50:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:to:cc:references:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=ePCwDuglP6ptjD2NpXlIDWkvZ1VJCXmrzLkkAA2bpgs=; b=Z3xqa2R0t00kEa3dKz62Mb6vkmFh4MWJHoK0pLSLBBwgr5Y6NuWhVLf3YaObir1vim catIx5I55BlfaNX6V14rqkpa/v2/LYvJU4SHAj5FFTCoyXhvqiJuTzQLcvZ/eZ/EhulG 7BNGsScXPYxTEGQ2guXA9LyU7Rr37Cv7K5bKHAI/2vIPjq+Nn+/jbua8j/ZkjdOSCcV/ QtVIuIckKpnjgbbLjiRFhUCKYLaIxZuDKiQCvXNqenLtG7L+IiY9Pd9OS0qA9yYUF//X KU54ZMJD7oAft7Y2gHP/flUF2lsodiK40WezOj3mRP5ekvfVKSi70LfaWWpRZ5DhXfhO +kDQ== X-Gm-Message-State: AElRT7EPwxvwcqD2mtm9SKLyXZinG+G02s/5fH8c6mcpxBT2spA3Xgjm 2Yz4vRiMMC5eYBs8WNjFht/NQw== X-Google-Smtp-Source: AG47ELuKlQt8ZNl86ec5Jt5g5y8eEsMMlY1fvztp2jCl9wNNDt5g6NcDlUCrpmVKPOnAv73wWEMQmg== X-Received: by 10.237.52.162 with SMTP id x31mr45480989qtd.19.1520621456070; Fri, 09 Mar 2018 10:50:56 -0800 (PST) Received: from localhost.localdomain (c-24-61-8-151.hsd1.ma.comcast.net. [24.61.8.151]) by smtp.gmail.com with ESMTPSA id k29sm1027939qtc.45.2018.03.09.10.50.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Mar 2018 10:50:55 -0800 (PST) Reply-To: jesper.pedersen@redhat.com Subject: Re: [HACKERS] Runtime Partition Pruning To: David Rowley Cc: Amit Langote , Rajkumar Raghuwanshi , Beena Emerson , Alvaro Herrera , Robert Haas , amul sul , "pgsql-hackers@postgresql.org" , Dilip Kumar References: <31e27e19-eaf6-642f-8eb6-9cc7528fa57b@lab.ntt.co.jp> <2dbe3de6-ad07-655f-1278-356709cbf185@lab.ntt.co.jp> From: Jesper Pedersen Organization: Red Hat Message-ID: <95dec133-7654-ce27-a7af-c91b0e58ad27@redhat.com> Date: Fri, 9 Mar 2018 13:50:54 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi David, On 03/01/2018 08:29 PM, David Rowley wrote: >> 0004 fails "make check-world" due to >> >> pg_restore: [archiver (db)] Error while PROCESSING TOC: >> pg_restore: [archiver (db)] Error from TOC entry 670; 1259 49954 TABLE >> boolp_f jpedersen >> pg_restore: [archiver (db)] could not execute query: ERROR: syntax error at >> or near "false" >> LINE 24: ..." ATTACH PARTITION "public"."boolp_f" FOR VALUES IN (false); > > The tests seem to have stumbled on a pg_dump bug which causes it to > produce syntax that's not valid (currently) > > I should be able to stop my patch failing the test by dropping that > table, which I should have been doing anyway. > I've added that thread to the Open Items list. > Thanks for the review and in advance for the future review. > > I'll delay releasing a new patch as there's some discussion over on > the faster partition pruning thread which affects this too [1] > > [1] https://www.postgresql.org/message-id/CA+Tgmoa4D1c4roj7L8cx8gkkeBWAZD=MTcXKxTwBnsLRHD3rig@mail.gmail.com > Sure, 0003-0005 depends on that thread. 0002 is refactoring so that one is ready. In 0004 should we add a HASH based test case, -- test.sql -- -- verify pruning in hash partitions create table hashp (a int primary key, b int) partition by hash (a); create table hashp_0 partition of hashp for values with (modulus 2, remainder 0); create table hashp_1 partition of hashp for values with (modulus 2, remainder 1); insert into hashp values (0,0), (1,1), (2,2), (3,3); prepare q1 (int) as select * from hashp where a = $1; execute q1 (1); execute q1 (1); execute q1 (1); execute q1 (1); execute q1 (1); explain (analyze, costs off, summary off, timing off) execute q1 (1); explain (analyze, costs off, summary off, timing off) execute q1 (3); deallocate q1; drop table hashp; -- test.sql -- Also, should 0004 consider the "Parallel Append" case, aka -- parallel.sql -- CREATE TABLE t1 ( a integer NOT NULL, b integer NOT NULL ) PARTITION BY HASH (b); CREATE TABLE t1_p00 PARTITION OF t1 FOR VALUES WITH (MODULUS 4, REMAINDER 0); CREATE TABLE t1_p01 PARTITION OF t1 FOR VALUES WITH (MODULUS 4, REMAINDER 1); CREATE TABLE t1_p02 PARTITION OF t1 FOR VALUES WITH (MODULUS 4, REMAINDER 2); CREATE TABLE t1_p03 PARTITION OF t1 FOR VALUES WITH (MODULUS 4, REMAINDER 3); INSERT INTO t1 (SELECT i, i FROM generate_series(1, 1000000) AS i); PREPARE q1 (int) AS SELECT * FROM t1 WHERE a = $1; EXECUTE q1 (5432); EXECUTE q1 (5432); EXECUTE q1 (5432); EXECUTE q1 (5432); EXECUTE q1 (5432); EXPLAIN (ANALYZE, COSTS OFF, SUMMARY OFF, TIMING OFF) EXECUTE q1 (5432); DEALLOCATE q1; DROP TABLE t1; -- parallel.sql -- Best regards, Jesper