From: | Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com> |
---|---|
To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Cc: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com>, Beena Emerson <memissemerson(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, amul sul <sulamul(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Subject: | Re: [HACKERS] Runtime Partition Pruning |
Date: | 2018-03-09 18:50:54 |
Message-ID: | 95dec133-7654-ce27-a7af-c91b0e58ad27@redhat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | David Steele | 2018-03-09 18:51:14 | Re: PATCH: Configurable file mode mask |
Previous Message | Claudio Freire | 2018-03-09 18:41:29 | Re: Faster inserts with mostly-monotonically increasing values |