Re: Partition pruning for Star Schema
От | Mark Kirkwood |
---|---|
Тема | Re: Partition pruning for Star Schema |
Дата | |
Msg-id | 4493a2fe-d31f-9466-134e-436456a60ed2@catalyst.net.nz обсуждение исходный текст |
Ответ на | Re: Partition pruning for Star Schema (Mark Kirkwood <mark.kirkwood@catalyst.net.nz>) |
Ответы |
Re: Partition pruning for Star Schema
|
Список | pgsql-hackers |
On 04/12/17 17:20, Mark Kirkwood wrote: > On 04/12/17 16:08, Ashutosh Bapat wrote: > >> On Sun, Dec 3, 2017 at 5:56 AM, legrand legrand >> <legrand_legrand@hotmail.com> wrote: >>> Hello, >>> >>> I have a typical star schema, having dimension tables "product", >>> "calendar" >>> and "country" and a fact table "sales". >>> This fact table is partitionned by time (range by month) and country >>> (list). >>> >>> Will query like: >>> >>> select product.name, calendar.month, sum(sales.net_price) >>> from sales >>> inner join product on (product.id = sales.cust_id) >>> inner join country on (country.id = sales.country_id) >>> inner join calendar on (calendar.id = sales.calendar_id) >>> where >>> country.name = 'HERE' >>> and calendar.year = '2017' >>> group by product.name,calendar.month >>> >>> be able to identify needed partitions ? >>> >> AFAIU partition pruning, it works only with the partition key columns. >> So, if country.name and calendar.year are the partition keys partition >> pruning would identify the needed partitions from those tables. But >> planner doesn't know that calendar.year is somehow related to >> calendar.id and then transfer that knowledge so that partitions of >> sales can be identified. >> > > If you can get your code to perform a star transformation on this type > of query, then you might see some partition pruning. > Actually it won't - sorry. To get that to work, you would need to evaluate the additional subqueries to produce fixed values! The patch for 'runtime partition pruning' might be what you want tho. Cheers Mark
В списке pgsql-hackers по дате отправления: