force partition pruning

From: Niels Jespersen <NJN(at)dst(dot)dk>
To: "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: force partition pruning
Date: 2021-05-10 11:39:17
Message-ID: a6fb9208ead848629db9c8cb0a5e3d0c@dst.dk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi all

I need a litte advice on how to

Postgres 13.2

A metadata query pulls partition keys:

select m.period_version from register.register_metadata m where m.current_version and m.period between '201712' and '201912' ;

A query using these in an in-list easily makes the planner do partition pruning.

select * from register.register d where d.period_version in ('201712_1', '201812_1', '201912_1');

However combining the metadataquery into the dataquery makes the planner decide to scan all partitions.

select * from register.register d where d.period_version in (select m.period_version from register.register_metadata m where m.current_version and m.period between '201712' and '201912');

I am quite aware that the latter query requires partition pruning to take place during execution not during planning.

My question here is how do I package the two-step proces into an interface that analysts can actually use?

One possibility is to have a prepare step that creates a temporary view with the hard-coded values built-in. And then query data via the temp view. This works ok, but there is an issue with possible naming conflicts on the temp view (not that this could not be worked around).

Ideally I would like a function to figure out the query and then return the data from that dynamically executed query. Complicating matters is the fact that there are more than one set of data/metatable tables and each datatable has a different set of columns. This excludes a table returning function since that must list the columns present.

Best regards

Niels Jespersen
Chief Adviser
IT Center

Mobile phone:+45 42 42 93 73
Email: njn(at)dst(dot)dk

Statistics Denmark, Sejrøgade 11, DK-2100 Copenhagen
www.dst.dk/en<https://www.dst.dk/en> | Twitter<https://twitter.com/dstdk> | LinkedIn<https://www.linkedin.com/company/statistics-denmark/> | Facebook<https://www.facebook.com/danmarksstatistik>

[cid:image001(dot)png(at)01D745A1(dot)DEE94640]

Responses

Browse pgsql-general by date

  From Date Subject
Next Message cen 2021-05-10 11:44:36 Re: Copyright vs Licence
Previous Message Ron 2021-05-10 10:08:19 Re: Copyright vs Licence