Re: Query Plan Performance on Partitioned Table - Mailing list pgsql-performance

From Rural Hunter
Subject Re: Query Plan Performance on Partitioned Table
Date
Msg-id CAOe1oo8nCEZnijp7_Ba9MZWUHg4jQnYpuPUwu_hU1M1HBQcJEA@mail.gmail.com
Whole thread Raw
In response to Re: Query Plan Performance on Partitioned Table  (Pietro Pugni <pietro.pugni@gmail.com>)
Responses Re: Query Plan Performance on Partitioned Table  (Pietro Pugni <pietro.pugni@gmail.com>)
List pgsql-performance
article_729 has about 0.8 million rows. The rows of the children tables are variance from several thousands to dozens of millions. How can it help to create index on the partition key?

2015-08-12 1:03 GMT+08:00 Pietro Pugni <pietro.pugni@gmail.com>:

Hi Rural Hunter,
Try to create an index on cid attribute.
How many rows has article_729?

Pietro Pugni

Il 11/ago/2015 16:51, "Rural Hunter" <ruralhunter@gmail.com> ha scritto:
yes i'm very sure. from what i observed, it has something to do with the concurrent query planing. if i disconnect other connections, the plan is very quick.

2015-08-11 22:42 GMT+08:00 Maxim Boguk <maxim.boguk@gmail.com>:


Check constraints:
    "article_729_cid_check" CHECK (cid = 729)



Used partition schema looks very simple and straightforward, and should have no issues with 80 partitions.
Are you sure that you have only 80 partitions but not (lets say) 800?
Are every other partition of the article table use the same general idea of partition check (cid=something)?

 
Maxim Boguk
Senior Postgresql DBA
http://www.postgresql-consulting.ru/

Phone RU: +7 910 405 4718
Phone AU: +61 45 218 5678

LinkedIn: http://www.linkedin.com/pub/maksym-boguk/80/b99/b1b
Skype: maxim.boguk
Jabber: maxim.boguk@gmail.com
МойКруг: http://mboguk.moikrug.ru/

"People problems are solved with people.
If people cannot solve the problem, try technology.
People will then wish they'd listened at the first stage."




pgsql-performance by date:

Previous
From: Pietro Pugni
Date:
Subject: Re: Query Plan Performance on Partitioned Table
Next
From: robbyc
Date:
Subject: Slow Query