Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, Amit Langote <amitlangote09@gmail.com>, Yuya Watari <watari.yuya@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Dmitry Dolgov <9erthalion6@gmail.com>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>, jian he <jian.universality@gmail.com>, Alena Rybakina <lena.ribackina@yandex.ru>, Andrei Lepikhov <a.lepikhov@postgrespro.ru>, Thom Brown <thom@linux.com>, Zhang Mingli <zmlpostgres@gmail.com>
Date: 2025-04-08T04:20:04Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Update wording in optimizer/README for EquivalenceClasses

  2. Speedup child EquivalenceMember lookup in planner

  3. Allow planner to use Merge Append to efficiently implement UNION

  4. Remove trailing zero words from Bitmapsets

  5. Make Vars be outer-join-aware.

  6. Avoid making commutatively-duplicate clauses in EquivalenceClasses.

David Rowley <dgrowleyml@gmail.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