PostgreSQL: Partitioned Table vs Non Partitioned Table (Part 3) - Comment Page: 1

Updated on September 7, 2010 by JR 12 comments

This article compares the speed and performance of queries between partitioned and non partitioned PostgreSQL tables. However, it is important to remember that the PostgreSQL tables partitioning has also another benefits, than the better performance on queries. More information about other benefits from the first part 'Howto create PostgreSQL table partitioning (Part 1)'. This is comparision between partitioned and non partitioned PostgreSQL tables. The same tests were carried out with and without indices, because using the indices, it is no longer very meaningful example on table, which has one billion rows of data (if the table is not partitioned). This comparison is used an example of...

See full post →

12 comments on “PostgreSQL: Partitioned Table vs Non Partitioned Table (Part 3) - Comment Page: 1”

Hello,

Thanks for writing such a great tutorial on PostgreSQL Table Partition. I enjoy reading it very much.

I have some question in your tutorial.

Based on http://www.if-not-true-then-false.com/2009/12/performance-testing-between-partitioned-and-non-partitioned-postgresql-tables-part-3/

Example 3a. Select MAX impressions on 25 November 2010. (Day field indexed)

By using

SELECT MAX(impressions) FROM impressions_by_day_non_partioned 
WHERE day = '2010-11-25';

How does PostgreSQL smart enough to know he need to look for table


CREATE TABLE impressions_by_day_y2010m11ms2 (
	PRIMARY KEY (advertiser_id, day), 
	CHECK ( day >= DATE '2010-11-01' AND day = DATE '2010-11-01' AND day < DATE '2011-01-01') ?

Thanks!

Hi,

Thank you for your comment. Glad to hear that my writings are enjoyable to read.

And in response to your question:
Apparently, you mean the 3a query to table “impressions_by_day_partitioned”, not to table “impressions_by_day_non_partioned”?

The first part (Howto create PostgreSQL table partitioning (Part 1)) in section five, I tell about constraint_exclusion. Constraint_exclusion is a query optimization technique that improves performance for partitioned tables. I can show you a example:


SET constraint_exclusion = off;

EXPLAIN ANALYZE SELECT MAX(impressions) FROM impressions_by_day_partitioned WHERE day = '2010-11-25';

                                                                                            QUERY PLAN                                                                                            
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Aggregate  (cost=372389.40..372389.41 rows=1 width=4) (actual time=10609.647..10609.649 rows=1 loops=1)
   ->  Append  (cost=18.80..372321.82 rows=27028 width=4) (actual time=7352.868..10563.892 rows=27143 loops=1)
         ->  Bitmap Heap Scan on impressions_by_day_partitioned  (cost=18.80..29.36 rows=10 width=4) (actual time=0.029..0.029 rows=0 loops=1)
               Recheck Cond: (day = '2010-11-25'::date)
               ->  Bitmap Index Scan on impressions_by_day_partitioned_pkey  (cost=0.00..18.80 rows=10 width=0) (actual time=0.019..0.019 rows=0 loops=1)
                     Index Cond: (day = '2010-11-25'::date)
         ->  Index Scan using impressions_by_day_partitioned_y2009m1ms2_day on impressions_by_day_partitioned_y2009m3ms2 impressions_by_day_partitioned  (cost=0.00..8.75 rows=1 width=4) (actual time=0.034..0.034 rows=0 loops=1)
               Index Cond: (day = '2010-11-25'::date)
         ->  Index Scan using impressions_by_day_partitioned_y2009m3ms2_day on impressions_by_day_partitioned_y2009m3ms2 impressions_by_day_partitioned  (cost=0.00..8.75 rows=1 width=4) (actual time=0.034..0.034 rows=0 loops=1)
               Index Cond: (day = '2010-11-25'::date)
         ->  Index Scan using impressions_by_day_partitioned_y2009m5ms2_day on impressions_by_day_partitioned_y2009m5ms2 impressions_by_day_partitioned  (cost=0.00..8.75 rows=1 width=4) (actual time=0.016..0.016 rows=0 loops=1)
               Index Cond: (day = '2010-11-25'::date)
         ->  Index Scan using impressions_by_day_partitioned_y2009m7ms2_day on impressions_by_day_partitioned_y2009m7ms2 impressions_by_day_partitioned  (cost=0.00..8.75 rows=1 width=4) (actual time=0.015..0.015 rows=0 loops=1)
               Index Cond: (day = '2010-11-25'::date)
[...]
         ->  Index Scan using impressions_by_day_partitioned_y2011m1ms2_day on impressions_by_day_partitioned_y2011m1ms2 impressions_by_day_partitioned  (cost=0.00..8.46 rows=1 width=4) (actual time=0.017..0.017 rows=0 loops=1)
               Index Cond: (day = '2010-11-25'::date)
         ->  Index Scan using impressions_by_day_partitioned_y2011m3ms2_day on impressions_by_day_partitioned_y2011m3ms2 impressions_by_day_partitioned  (cost=0.00..8.47 rows=1 width=4) (actual time=0.008..0.008 rows=0 loops=1)
               Index Cond: (day = '2010-11-25'::date)
         ->  Index Scan using impressions_by_day_partitioned_y2011m5ms2_day on impressions_by_day_partitioned_y2011m5ms2 impressions_by_day_partitioned  (cost=0.00..8.46 rows=1 width=4) (actual time=0.007..0.007 rows=0 loops=1)
               Index Cond: (day = '2010-11-25'::date)
         ->  Index Scan using impressions_by_day_partitioned_y2011m7ms2_day on impressions_by_day_partitioned_y2011m7ms2 impressions_by_day_partitioned  (cost=0.00..8.46 rows=1 width=4) (actual time=0.007..0.007 rows=0 loops=1)
               Index Cond: (day = '2010-11-25'::date)
         ->  Index Scan using impressions_by_day_partitioned_y2011m9ms2_day on impressions_by_day_partitioned_y2011m9ms2 impressions_by_day_partitioned  (cost=0.00..8.45 rows=1 width=4) (actual time=0.007..0.007 rows=0 loops=1)
               Index Cond: (day = '2010-11-25'::date)
         ->  Index Scan using impressions_by_day_partitioned_y2011m11ms2_day on impressions_by_day_partitioned_y2011m11ms2 impressions_by_day_partitioned  (cost=0.00..8.46 rows=1 width=4) (actual time=0.008..0.008 rows=0 loops=1)
               Index Cond: (day = '2010-11-25'::date)
[...]

So as you can see it loops thru all tables if constraint exclusion is off, and then query is much slower than query to single table. With constraint exclusion enabled, the PostgreSQL query planner will examine the constraints of each partition and try to prove that the partition need not be scanned because it could not contain any rows meeting the query’s WHERE clause. When the planner can prove this, it excludes the partition from the query plan, as following:


SET constraint_exclusion = on;

EXPLAIN ANALYZE SELECT MAX(impressions) FROM impressions_by_day_partitioned WHERE day = '2010-11-25';
                                                                             QUERY PLAN                                                                              
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Aggregate  (cost=29980.57..29980.58 rows=1 width=4) (actual time=699.152..699.154 rows=1 loops=1)
   ->  Append  (cost=18.80..29913.06 rows=27005 width=4) (actual time=0.173..653.400 rows=27143 loops=1)
         ->  Bitmap Heap Scan on impressions_by_day_partitioned  (cost=18.80..29.36 rows=10 width=4) (actual time=0.013..0.013 rows=0 loops=1)
               Recheck Cond: (day = '2010-11-25'::date)
               ->  Bitmap Index Scan on impressions_by_day_partitioned_pkey  (cost=0.00..18.80 rows=10 width=0) (actual time=0.008..0.008 rows=0 loops=1)
                     Index Cond: (day = '2010-11-25'::date)
         ->  Index Scan using impressions_by_day_partitioned_y2010m11ms2 on impressions_by_day_partitioned_y2010m11ms2 impressions_by_day_partitioned  (cost=0.00..8.75 rows=1 width=4) (actual time=0.015..0.015 rows=0 loops=1)
               Index Cond: (day = '2010-11-25'::date)

And now same query to partitioned table works lightning fast compared to same query to single table.

And after this long example, the simple answer to your question is that: this logic (exclude not needed tables) is built into PostgreSQL Query Planner.

Yan Cheng CHEOK
28th January 2010, 10:00 am

Thank you very much for your explanation.

I am now following your tutorial, to implement table partition in one of my application.

As my table rows grow into billions (very soon), I can feel that the query performance will some how drop.

Table partition seems to be the answer of my problem.

However, during implementation, I face some problem on it which I had mentioned in PostgreSQL general mailing list. I was wondering whether you are free enough to take a look, and input me some suggestion?

http://archives.postgresql.org/pgsql-general/2010-01/msg01184.php

Sorry if this is not the place to ask for your advice. But I cannot locate any of your contact.

Thank you very much.
Reply
- JR
  28th January 2010, 4:22 pm
  Sounds like so that the partitioning is really a good solution in your situation, when the rows are growing and growing.
  
  This is good place to ask advice for this problem, if I understand your problem rightly then my answer is very simple.
  
  You have following in your trigger:
```
[...]
    -- NOTICE:  IN unit_insert_trigger, table is unit_0
    -- NOTICE:  IN unit_insert_trigger, NEW.unit_id is 28
    raise notice 'IN unit_insert_trigger, table is %', unit_table_name;
    raise notice 'IN unit_insert_trigger, NEW.unit_id is %', NEW.unit_id;
    
    EXECUTE 'INSERT INTO ' || quote_ident(unit_table_name) || 
    '(unit_id, fk_lot_id, cycle) VALUES (' || 
    NEW.unit_id || ',' || NEW.fk_lot_id || ',' || NEW.cycle || ')';
    
    RETURN NULL;
END;
```
  Change that RETURN NULL; to RETURN NEW; and then RETURNING * should work as expected.
  
  So fixed version should look like that:
```
[...]
    -- NOTICE:  IN unit_insert_trigger, table is unit_0
    -- NOTICE:  IN unit_insert_trigger, NEW.unit_id is 28
    raise notice 'IN unit_insert_trigger, table is %', unit_table_name;
    raise notice 'IN unit_insert_trigger, NEW.unit_id is %', NEW.unit_id;
    
    EXECUTE 'INSERT INTO ' || quote_ident(unit_table_name) || 
    '(unit_id, fk_lot_id, cycle) VALUES (' || 
    NEW.unit_id || ',' || NEW.fk_lot_id || ',' || NEW.cycle || ')';
    
    RETURN NEW;
END;
```
  Did this solve your problem?
  
  And true, here is not my contact details, but I would shortly add a contact form :)
  Reply
Yan Cheng CHEOK
29th January 2010, 8:44 am

But that will create additional problem. A duplicated entry will be created at parent table. To demo the problem :

(1) create database named “tutorial_partition”

(2) perform the following SQL query :

CREATE TABLE impressions_by_day (
advertiser_id SERIAL NOT NULL,
day DATE NOT NULL DEFAULT CURRENT_DATE,
impressions INTEGER NOT NULL,
PRIMARY KEY (advertiser_id, day)
);

CREATE OR REPLACE FUNCTION insert_table()
RETURNS void AS
$BODY$DECLARE
_impressions_by_day impressions_by_day;
BEGIN
INSERT INTO impressions_by_day(impressions ) VALUES(888) RETURNING * INTO _impressions_by_day;

RAISE NOTICE ‘After insert, the returned advertiser_id is %’, _impressions_by_day.advertiser_id;
END;$BODY$
LANGUAGE ‘plpgsql’ VOLATILE;
ALTER FUNCTION insert_table() OWNER TO postgres;

CREATE TABLE impressions_by_day_y2010m1ms2 (
PRIMARY KEY (advertiser_id, day),
CHECK ( day >= DATE ‘2010-01-01’ AND day = DATE ‘2010-01-01’ AND NEW.day < DATE '2010-03-01' ) THEN
INSERT INTO impressions_by_day_y2010m1ms2 VALUES (NEW.*);
ELSE
RAISE EXCEPTION 'Date out of range. Something wrong with the impressions_by_day_insert_trigger() function!';
END IF;
RETURN NEW;
END;
$$
LANGUAGE plpgsql;

CREATE TRIGGER insert_impressions_by_day_trigger
BEFORE INSERT ON impressions_by_day
FOR EACH ROW EXECUTE PROCEDURE impressions_by_day_insert_trigger();

(3) execute

SELECT * FROM insert_table()

If you impressions_by_day_y2010m1ms2, everything looks fine.

However, if you exam impressions_by_day, it will contains duplicated item.

http://sites.google.com/site/yanchengcheok/Home/returningnew.PNG?attredirects=0

Any idea?

Thanks!
Reply

By the way, do you think it is possible to solve by

CREATE RULE

Not sure, cause I am not sure use CREATE RULE instead of TRIGGER, is the way to implement table partition.

Actually yes, that RETURN NEW cause new problems, because if the function returns NEW and not NULL value, then insert to table is run normally.

I also tried that CREATE RULE method, but it’s not working too, because it’s not possible write following RULES:


CREATE RULE impressions_by_day_insert_y2010m1ms2 AS
ON INSERT TO impressions_by_day WHERE
    ( day >= DATE '2010-01-01' AND day < DATE '2010-03-01' )
DO INSTEAD
    INSERT INTO impressions_by_day__y2010m1ms2 VALUES (NEW.advertiser_id,NEW.day,NEW.impressions) RETURNING *;

Because RETURNING on rule is not allowed, if there is some WHERE condition.

Error message is following:


[test]> insert into impressions_by_day values (10,current_date,111) returning *;
ERROR:  cannot perform INSERT RETURNING on relation "impressions_by_day"
HINT:  You need an unconditional ON INSERT DO INSTEAD rule with a RETURNING clause.

Therefore it seems that PostgreSQL does not support this feature at all, but I wrote you a little (dirty) hack, which could get this to work. ;)

So I think following should work:


CREATE TABLE impressions_by_day (
	advertiser_id SERIAL NOT NULL,
	day DATE NOT NULL DEFAULT CURRENT_DATE,
	impressions INTEGER NOT NULL,
        PRIMARY KEY (advertiser_id, day)
);

CREATE TABLE impressions_by_day_temp (
	advertiser_id SERIAL NOT NULL,
	day DATE NOT NULL DEFAULT CURRENT_DATE,
	impressions INTEGER NOT NULL,
	PRIMARY KEY (advertiser_id, day)
);

CREATE OR REPLACE FUNCTION insert_table()
  RETURNS void AS
$BODY$DECLARE
    _impressions_by_day impressions_by_day;
BEGIN
    INSERT INTO impressions_by_day(impressions ) VALUES(888) RETURNING  * INTO _impressions_by_day;

    RAISE NOTICE 'After insert, the returned advertiser_id is %', _impressions_by_day.advertiser_id;
END;$BODY$
  LANGUAGE 'plpgsql' VOLATILE;
ALTER FUNCTION insert_table() OWNER TO postgres;

CREATE TABLE impressions_by_day_y2010m1ms2 (
	PRIMARY KEY (advertiser_id, day), 
	CHECK ( day >= DATE '2010-01-01' AND day < DATE '2010-03-01' )
) INHERITS (impressions_by_day);

CREATE INDEX impressions_by_day_y2010m1ms2_index ON impressions_by_day_y2010m1ms2 (day);

CREATE OR REPLACE RULE impressions_by_day_insert AS
ON INSERT TO impressions_by_day 
DO INSTEAD INSERT INTO impressions_by_day_temp VALUES (NEW.*) RETURNING *;

CREATE OR REPLACE FUNCTION impressions_by_day_insert_trigger()
RETURNS TRIGGER AS $$
BEGIN
	IF ( NEW.day >= DATE '2010-01-01' AND NEW.day < DATE '2010-03-01' ) THEN 
		INSERT INTO impressions_by_day_y2010m1ms2 VALUES (NEW.*); 
	ELSE
		RAISE EXCEPTION 'Date out of range.  Something wrong with the impressions_by_day_insert_trigger() function!';
	END IF;
	DELETE FROM impressions_by_day_temp;
	RETURN NEW;
END;
$$
LANGUAGE plpgsql;

CREATE TRIGGER insert_impressions_by_day_trigger 
	BEFORE INSERT ON impressions_by_day_temp  
	FOR EACH ROW EXECUTE PROCEDURE impressions_by_day_insert_trigger();

So this work little differently than normal PostgreSQL partitioning: main table has rule, which inserts to temp table. Then trigger function inserts that to right partition.

Maybe this works for you?

Yan Cheng CHEOK
2nd February 2010, 5:43 am

Thanks.

Instead applying your suggestion, I use a more straight forward approach.

Instead of calling INSERT… into unit, and hoping trigger function will handle the right job.

I will call insert directly on the child table.

— There is reason behind why we do not want to use trigger technique for table unit.
— Please refer to : http://archives.postgresql.org/pgsql-general/2010-01/msg01184.php
— INSERT INTO unit(fk_lot_id, cycle)
— VALUES(_lotID, _cycle) RETURNING unit_id INTO _unit_id;
unit_table_index = _lotID;
unit_table_name = ‘unit_’ || _lotID;

IF NOT EXISTS(SELECT * FROM information_schema.tables WHERE table_name = unit_table_name) THEN
EXECUTE ‘CREATE TABLE ‘ || quote_ident(unit_table_name) || ‘
(
unit_id bigserial NOT NULL,
fk_lot_id bigint NOT NULL,
CHECK (fk_lot_id = ‘ || (unit_table_index) || ‘),
CONSTRAINT pk_unit_’ || unit_table_index || ‘_id PRIMARY KEY (unit_id),
CONSTRAINT fk_lot_’ || unit_table_index || ‘_id FOREIGN KEY (fk_lot_id) REFERENCES lot (lot_id) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE CASCADE
) INHERITS (unit);’;

EXECUTE ‘CREATE INDEX fk_lot_’ || unit_table_index || ‘_id_idx ON ‘ || quote_ident(unit_table_name) || ‘(fk_lot_id);’;
END IF;

EXECUTE ‘INSERT INTO ‘ || quote_ident(unit_table_name) || ‘(fk_lot_id, cycle) VALUES (‘ || _lotID || ‘,’ || _cycle || ‘) RETURNING unit_id’
INTO _unit_id;

_unit.unit_id = _unit_id;
_unit.fk_lot_id = _lotID;
_unit.cycle = _cycle;
Reply
- JR
  2nd February 2010, 1:17 pm
  
  Really nice to hear that you got the problem resolved and got it to work, just as you wanted. :)
  
  Inserting directly on the child table is very good and robust solution in this case.
  Reply
dragonfly
7th March 2014, 8:04 pm

well not if you depend on the parent table to keep the id unique on all child tables
Reply
- JR
  7th March 2014, 9:56 pm
  
  You can always use one sequence nextval to make sure that you have always unique id, but normal partitioning setup this shouldn’t be problem.
  Reply
roger
4th January 2018, 6:34 pm

Possible to get updated stats with a recent version of postgres? :)
Reply

12 comments on “PostgreSQL: Partitioned Table vs Non Partitioned Table (Part 3) - Comment Page: 1”

Leave a Reply Cancel reply