Re: [HACKERS] Runtime Partition Pruning - Mailing list pgsql-hackers

From Jesper Pedersen
Subject Re: [HACKERS] Runtime Partition Pruning
Date
Msg-id 95dec133-7654-ce27-a7af-c91b0e58ad27@redhat.com
Whole thread Raw
In response to Re: [HACKERS] Runtime Partition Pruning  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: [HACKERS] Runtime Partition Pruning  (David Rowley <david.rowley@2ndquadrant.com>)
List 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


pgsql-hackers by date:

Previous
From: Claudio Freire
Date:
Subject: Re: Faster inserts with mostly-monotonically increasing values
Next
From: David Steele
Date:
Subject: Re: PATCH: Configurable file mode mask