From: | Michał Kłeczek <michal(at)kleczek(dot)org> |
---|---|
To: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: DRAFT: Pass sk_attno to consistent function |
Date: | 2024-07-26 08:10:38 |
Message-ID: | DE2605C0-07C4-4477-9DB6-3BC4FE0387D1@kleczek.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 26 Jul 2024, at 01:28, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> wrote:
>
> All in all, this still seems like a very (very) specific optimization,
> of which I'm not sure that it is generalizable. However, array
> introspection and filtering for SAOP equality checks feel like a
> relatively easy (?) push-down optimization in (e.g.) runtime partition
> pruning (or planning); isn't that even better patch potential here?
The issue is not partition pruning for SAOP - it works fine. The issue is lack of SAOP support in GIST.
Because I cannot use SAOP I have two options:
1) LATERAL JOIN (ie. iterate through input array elements, SELECT rows for each, merge results)
2) Implement a custom operator that emulates SAOP and provide consistent function for it. Additionally provide SAOP clause (redundantly) to enable partition pruning.
In case of 1):
- the query becomes convoluted with multiple redundant ORDER BY and LIMIT clauses
- unnecessary sort is performed (because we have to merge results of subqueries)
- some partitions are scanned multiple times (per each element in input array that happens to land in the same partition)
In case of 2):
- the whole input array is passed to consistent function for each partition so we unnecessarily search for non-existent rows
To fix the issue in 2) I need to somehow filter input array per partition - hence this patch.
Regards,
—
Michal
From | Date | Subject | |
---|---|---|---|
Next Message | Bertrand Drouvot | 2024-07-26 08:27:25 | Re: Restart pg_usleep when interrupted |
Previous Message | Hayato Kuroda (Fujitsu) | 2024-07-26 08:07:54 | RE: [Proposal] Add foreign-server health checks infrastructure |