Re: Partitioning and performance - Mailing list pgsql-general

From Melvin Davidson
Subject Re: Partitioning and performance
Date
Msg-id CANu8FixLUZJ9fT4mLrQQba6iKreNBP43JiDwyEAw_bXUcWEOOg@mail.gmail.com
Whole thread Raw
In response to Re: Partitioning and performance  (Ravi Krishna <sravikrishna3@gmail.com>)
Responses Re: Partitioning and performance
List pgsql-general
Generally, when you partition, data should only be in child tables, and the parent table should be empty, otherwise you defeat the purpose of parttioning.`

On Thu, May 28, 2015 at 12:25 PM, Ravi Krishna <sravikrishna3@gmail.com> wrote:
> Have you set up constraints on the partitions? The planner needs to know
> what is in the child tables so it can avoid scanning them.

Yes. each child table is defined as follows

CREATE TABLE TSTESTING.ACCOUNT_PART1

 ( CHECK (ACCOUNT_ROW_INST BETWEEN 1001 and 271660))

 INHERITS (TSTESTING.ACCOUNT);

ALTER TABLE TSTESTING.ACCOUNT_PART1 ADD CONSTRAINT ACCOUNT_PART1_PKEY
PRIMARY KEY (ACCOUNT_ROW_INST);

Perhaps I was not clear. The planner is excluding partitions which can
not contain the rows looked up in the WHERE clause. However it is
still scanning the parent table.

Aggregate (cost=8.45..8.46 rows=1 width=0)
-> Append (cost=0.00..8.44 rows=2 width=0)
-> Seq Scan on account (cost=0.00..0.00 rows=1 width=0)
Filter: (account_row_inst = 101)
-> Index Only Scan using account_part1_pkey on account_part1
(cost=0.42..8.44 rows=1 width=0)
Index Cond: (account_row_inst = 101)
(6 rows)


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general



--
Melvin Davidson
I reserve the right to fantasize.  Whether or not you
wish to share my fantasy is entirely up to you.

pgsql-general by date:

Previous
From: Jan Lentfer
Date:
Subject: Re: Partitioning and performance
Next
From: Jan Lentfer
Date:
Subject: Re: Partitioning and performance