On Wed, May 12, 2021 at 10:19:17PM +0900, Amit Langote wrote:
> (Sorry about being very late to this thread.)
>
> > Would it be unreasonable of us to ask for a worked-out example making
> > use of the proposed hook? That'd go a long way towards resolving the
> > question of whether you can do any
(Sorry about being very late to this thread.)
On Sun, Mar 7, 2021 at 3:09 AM Tom Lane wrote:
> Peter Eisentraut writes:
> > On 07.05.20 10:11, Erik Nordström wrote:
> >> I am looking for feedback on the possibility of adding a table expansion
> >> hook to PostgreSQL (see attached patch).
>
> > U
On Wed, May 12, 2021 at 04:48:29PM +0900, yuzuko wrote:
> Hello,
>
> > Thank you all for the feedback and insights.
> >
> > Yes, the intention is to *replace* expand_inherited_rtentry() in the same
> > way planner_hook replaces standard_planner().
> >
>
> This patch is really useful. We are wor
Hello,
> Thank you all for the feedback and insights.
>
> Yes, the intention is to *replace* expand_inherited_rtentry() in the same way
> planner_hook replaces standard_planner().
>
This patch is really useful. We are working on developing hypothetical
partitioning as a feature of HypoPG[1][2],
Hi Erik,
> Thank you all for the feedback and insights.
>
> Yes, the intention is to *replace* expand_inherited_rtentry() in the same way
> planner_hook replaces standard_planner().
This patch probably doesn't need yet another reviewer, but since there
is a little controversy about if the hook s
Thank you all for the feedback and insights.
Yes, the intention is to *replace* expand_inherited_rtentry() in the same
way planner_hook replaces standard_planner().
Some background: TimescaleDB implements its own partitioning based on
inheritance that predates declarative partitioning. The extens
On Sat, Mar 06, 2021 at 01:09:10PM -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > On 07.05.20 10:11, Erik Nordström wrote:
> >> I am looking for feedback on the possibility of adding a table expansion
> >> hook to PostgreSQL (see attached patch).
>
> > Unlike the get_relation_info_hook, y
Peter Eisentraut writes:
> On 07.05.20 10:11, Erik Nordström wrote:
>> I am looking for feedback on the possibility of adding a table expansion
>> hook to PostgreSQL (see attached patch).
> Unlike the get_relation_info_hook, your proposed hook would *replace*
> expand_inherited_rtentry() rather
On 07.05.20 10:11, Erik Nordström wrote:
I am looking for feedback on the possibility of adding a table expansion
hook to PostgreSQL (see attached patch). The motivation for this is to
allow extensions to optimize table expansion. In particular, TimescaleDB
does its own table expansion in order
Status update for a commitfest entry.
This patch implements useful improvement and the reviewer approved the code. It
lacks a test, but looking at previously committed hooks, I think it is not
mandatory.
So, I move it to RFC.
The new status of this patch is: Ready for Committer
On Thu, 7 May 2020 at 05:11, Erik Nordström wrote:
>
> I am looking for feedback on the possibility of adding a table expansion
> hook to PostgreSQL (see attached patch). The motivation for this is to
> allow extensions to optimize table expansion. In particular, TimescaleDB
> does its own table
that sounds really really useful.
i can see a ton of use cases for that.
we also toyed with the idea recently of having pluggable FSM strategies.
that one could be quite useful as well.
regards,
hans
> On 07.05.2020, at 10:11, Erik Nordström wrote:
>
> Hi,
>
> I am lo
Hi,
I am looking for feedback on the possibility of adding a table expansion
hook to PostgreSQL (see attached patch). The motivation for this is to
allow extensions to optimize table expansion. In particular, TimescaleDB
does its own table expansion in order to apply a number of optimizations,
inc
13 matches
Mail list logo
