From: | Mats Taraldsvik <mats(dot)taraldsvik(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Fwd: Declarative partitioning and partition pruning/check |
Date: | 2022-04-19 12:39:12 |
Message-ID: | CAGs3qpTiKV_8PogNt3yofMCLWHN4kt_DrpmhJzQ47DZj-_DksQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
I'm re-trying this email here, as there were no answers in the psql-general
list. Hope that's ok. (please cc me when answering as I'm not subscribed
(yet) )
Hi,
I have tried to read about Oracle's spatial partitioning feature (
https://www.oracle.com/technetwork/database/enterprise-edition/spatial-twp-partitioningbp-10gr2-05-134277.pdf)
and wondered if something like this is possible with PostgreSQL (with
PostGIS):
The first part, getting the rows into the "right" partition isn't
especially interesting: Reduce every geometry to a point, and use the x and
y coordinates separately in a range partition. This is possible with
PostgreSQL as it is a normal range partition on double.
The second part is more interesting. Whenever the spatial index is
(implicitly or directly) used in a query, the partition pruning step
(during execution) checks the spatial index's root bounding box to
determine if the partition can be skipped.
Is this possible to achieve in PostgreSQL? There is already a function in
PostGIS to get the spatial index root bounding box
(_postgis_index_extent(tbl regclass, col text)), but I think the real issue
is that the actual SQL query might not even call the index directly (SELECT
* FROM a WHERE ST_Intersects(mygeom, a.geom) - the ST_Intersects function
uses the index internally).
Best Regards,
Mats Taraldsvik
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2022-04-19 13:39:28 | Re: Fwd: Declarative partitioning and partition pruning/check (+postgis) |
Previous Message | Thomas, Richard | 2022-04-19 11:59:41 | RE: PostgreSQL 10.20 crashes / Antivirus |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2022-04-19 12:39:30 | Re: TRAP: FailedAssertion("tabstat->trans == trans", File: "pgstat_relation.c", Line: 508 |
Previous Message | Daniel Gustafsson | 2022-04-19 12:35:57 | Re: Patch a potential memory leak in describeOneTableDetails() |