Re: [PoC] Reducing planning time when tables have many partitions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, Yuya Watari <watari(dot)yuya(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, jian he <jian(dot)universality(at)gmail(dot)com>, Alena Rybakina <lena(dot)ribackina(at)yandex(dot)ru>, Andrei Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru>, Thom Brown <thom(at)linux(dot)com>, Zhang Mingli <zmlpostgres(at)gmail(dot)com>
Subject: Re: [PoC] Reducing planning time when tables have many partitions
Date: 2025-04-08 04:20:04
Message-ID: 3886606.1744086004@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> I certainly could get on board with renaming if there's consensus to
> do so. I don't think that's going to happen in the next 9 hours. Is it
> worth pushing this out to v19 because we can't agree on the name of a
> struct field? I'd be disappointed if we miss this because of something
> so trivial.

Renaming functions or struct fields is hardly something that's forbidden
post-feature-freeze. I think you could go ahead while agreeing to
change that stuff later if there's consensus for it. At this point it
seems much more useful to get some buildfarm mileage on the patch.

(FWIW, I buy your argument that there's a limit to how much complexity
we should shove into the iterator.)

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2025-04-08 04:32:36 Re: Proposal - Allow extensions to set a Plan Identifier
Previous Message Andres Freund 2025-04-08 04:19:53 Re: pg_dump/restore failure (dependency?) on BF serinus