me if I have missed something in the meantime.
Thanks, Amit Langote
names like
v8-000x, instead of zipping them helps. Many folks (myself included)
will casually skip a zip file because of the small hassle of unzipping
just to read a patch. I once postponed reading such a patch and didn’t
get back to it for quite a while. :)
--
Thanks, Amit Langote
On Mon, Jul 14, 2025 at 5:04 PM Andrei Lepikhov wrote:
> On 14/7/2025 06:52, Amit Langote wrote:
> > On Fri, Jul 11, 2025 at 11:09 PM Andrei Lepikhov wrote:
> > To support that efficiently, the slot can store a new tts_min_valid
> > field to indicate the lowest attno
attributes
are collected during expression tree initialization, in a generic
enough way that any expression whose evaluation might involve a
deforming step will benefit.
--
Thanks, Amit Langote
[1]
https://www.postgresql.org/message-id/flat/20160722015605.hpthk7axm6sx2mur%40alap3.anarazel.de
On Thu, Jul 17, 2025 at 9:11 PM Amit Langote wrote:
> The refinements I described in my email above might help mitigate some
> of those executor-related issues. However, I'm starting to wonder if
> it's worth reconsidering our decision to handle pruning, locking, and
>
On Fri, Jun 20, 2025 at 9:30 PM Amit Langote wrote:
> On Thu, May 22, 2025 at 5:12 PM Amit Langote wrote:
> > I have pushed out the revert now.
> >
> > Note that I’ve only reverted the changes related to deferring locks on
> > prunable partitions. I’m planning to le
On Thu, Jul 17, 2025 at 12:03 PM Amit Langote wrote:
> On Thu, Jul 17, 2025 at 10:01 AM Richard Guo wrote:
> > On Thu, Jul 17, 2025 at 9:52 AM Tender Wang wrote:
> > > jian he 于2025年7月17日周四 07:39写道：
> > >> ExecEvalJsonCoercionFinish duplicate
later one.
Oops, you're right -- I must have copy-pasted without noticing the
duplicate. Thanks Jian for catching that. Will fix.
--
Thanks, Amit Langote
Thanks for the thoughts, Tom.
On Mon, Jul 14, 2025 at 11:29 PM Tom Lane wrote:
> Amit Langote writes:
> > Not quite -- the optimization doesn’t require changes to the tuple
> > header or representation. The existing deforming code already stops
> > once all requested
Hi,
On Fri, Jul 11, 2025 at 11:34 PM Andres Freund wrote:
> On 2025-07-11 11:22:36 +0900, Amit Langote wrote:
> > On Fri, Jul 11, 2025 at 5:55 AM Andres Freund wrote:
> > > On 2025-07-10 17:28:50 +0900, Amit Langote wrote:
> >
Thanks for the comments.
On Fri, Jul 11, 2025 at 11:09 PM Andrei Lepikhov wrote:
>
> On 11/7/2025 10:16, Amit Langote wrote:
> > Hi,
> >
> > I’ve been experimenting with an optimization that reduces executor
> > overhead by avoiding unnecessary attribute deforma
On Fri, Jul 11, 2025 at 6:58 PM Japin Li wrote:
> On Fri, 11 Jul 2025 at 17:16, Amit Langote wrote:
> > Hi,
> >
> > I’ve been experimenting with an optimization that reduces executor
> > overhead by avoiding unnecessary attribute deformation. Specifically,
>
on
to avoid enabling this optimization more broadly across plan nodes.
I'll post the PoC patches and performance measurements. Posting this
in advance to get feedback on the proposed direction and where best to
place attr_used.
--
Thanks,
Amit Langote
Hi Dilip,
Sorry for the late reply.
On Thu, Jul 3, 2025 at 1:24 PM Dilip Kumar wrote:
>
> On Wed, Jul 2, 2025 at 7:18 PM Amit Langote wrote:
>
> > Just to clarify -- I was hoping that, at least for SELECTs, we
> > wouldn’t need to lock all leaf partitions up front.
> &g
On Fri, Jul 11, 2025 at 5:55 AM Andres Freund wrote:
> On 2025-07-10 17:28:50 +0900, Amit Langote wrote:
> > On Thu, Jul 10, 2025 at 8:34 AM Andres Freund wrote:
> > > The performance gain unsurprisingly isn't significant (but seems
> > > repeatably
> >
On Thu, Jul 10, 2025 at 22:20 Amit Langote wrote:
> Fujita-san,
>
> On Wed, Jul 9, 2025 at 5:07 PM Etsuro Fujita
> wrote:
> > On Tue, Jul 1, 2025 at 11:55 AM Etsuro Fujita
> wrote:
> > > So I would
> > > like to propose to fix this by the following:
tored_generated_columns(root, rti))
That seems a bit expensive. It might be worth using *_valid flags to
avoid redundant table_open() calls like you're doing for transition
table checking. Maybe something to consider in a separate patch.
--
Thanks, Amit Langote
Hi Andres,
On Thu, Jul 10, 2025 at 8:34 AM Andres Freund wrote:
> On 2025-01-22 10:07:51 +0900, Amit Langote wrote:
> > On Fri, Jan 17, 2025 at 2:05 PM Amit Langote
> > wrote:
> > > Here's v5 with a few commit message tweaks.
> > >
> > > Barring o
On Wed, Jul 2, 2025 at 7:05 PM Etsuro Fujita wrote:
> On Tue, Jul 1, 2025 at 4:42 PM Amit Langote wrote:
> > On Tue, Jul 1, 2025 at 11:55 AM Etsuro Fujita
> > wrote:
> > > While working on something else, I noticed that while we disallow
> > > transition t
On Wed, Jul 2, 2025 at 1:04 PM Dilip Kumar wrote:
> On Tue, Jul 1, 2025 at 7:12 PM Amit Langote wrote:
> > I’ve been working on improving how we handle partition locking during
> > execution of generic plans. Specifically, I committed a patch to defer
> > locking of p
hat inserts also need to lock all partitions up front
when global indexes are present, due to cross-partition uniqueness
checks?
Let me know if I’ve misunderstood the design.
--
Thanks, Amit Langote
bles, but I think that that is too restrictive
> because some users might have been using such triggers, avoiding this
> problem by e.g., modifying only plain-table partitions.
+1
> So I would
> like to propose to fix this by the following: 1) disable using direct
> modify to modify foreign-table partitions if there are any
> transition-table triggers on the partitioned table, and then 2) throw
> an error in
> ExecARInsertTriggers()/ExecARUpdateTriggers()/ExecARDeleteTriggers()
> if they collects transition tuple(s) from a foreign-table partition.
Is (2) intended to catch cases that occur during a foreign insert and
foreign/non-direct update/delete?
--
Thanks, Amit Langote
On Tue, Jul 1, 2025 at 11:42 AM Amit Langote wrote:
> Hi Nagata-san,
>
> On Tue, Jul 1, 2025 at 11:02 AM Yugo Nagata wrote:
> >
> > Hi,
> >
> > I found typos in the comments of ExecInsertIndexTuples
> > that mention TUUI_{All, Summarizing} but they shou
the patch. Will push shortly.
--
Thanks, Amit Langote
On Thu, May 22, 2025 at 5:12 PM Amit Langote wrote:
> I have pushed out the revert now.
>
> Note that I’ve only reverted the changes related to deferring locks on
> prunable partitions. I’m planning to leave the preparatory commits
> leading up to that one in place unless anyo
bring this up while it's fresh.
--
Thanks, Amit Langote
On Thu, May 22, 2025 at 10:04 PM Tomas Vondra wrote:
> On 5/22/25 10:12, Amit Langote wrote:
> > Note that I’ve only reverted the changes related to deferring locks on
> > prunable partitions. I’m planning to leave the preparatory commits
> > leading up to that one in place
On Wed, May 21, 2025 at 7:22 PM Amit Langote wrote:
> Fair enough. I’ll revert this and some related changes shortly. WIP
> patch attached.
I have pushed out the revert now.
Note that I’ve only reverted the changes related to deferring locks on
prunable partitions. I’m planning to lea
On Wed, May 21, 2025 at 3:44 AM Tomas Vondra wrote:
> On 5/20/25 05:06, Tom Lane wrote:
> > Amit Langote writes:
> >> Pushed after some tweaks to comments and the test case.
> >
> > My attention was drawn to commit 525392d57 after observing that
> > Valgri
On Wed, May 21, 2025 at 12:38 AM Tom Lane wrote:
> Amit Langote writes:
> > Thanks for pointing out the hole in the current handling of
> > CachedPlan->stmt_list. You're right that the approach of preserving
> > the list structure while replacing its contents in-p
then we
may end up shelving the deferred locking idea entirely -- which would
be unfortunate, given how much it helps workloads that rely on generic
plans over large partitioned tables.
Let me know what you think -- I’ll hold off on posting a revert or a
replacement until we’ve agr
On Sat, May 3, 2025 at 1:18 AM Bruce Momjian wrote:
> On Fri, May 2, 2025 at 01:00:57PM +0900, Amit Langote wrote:
> > 1. Speed up execution of cached plans by deferring locks on partitions
> > subject to pruning (Amit Langote)
> > (bb3ec16e1, d47cbf474, cbc127917, 525392d57
s always for working on this.
I noticed the release notes currently combine several
partition-related commits under one item:
+
+
+
+Allow partitions to be pruned earlier and quicker, and skipped in
more places (Amit Langote, Ashutosh Bapat, Yuya Watari, David Rowley)
+§
+§
+§
+§
+§
+§
+
+
But I
On Wed, Apr 9, 2025 at 2:21 PM David Rowley wrote:
> On Wed, 9 Apr 2025 at 17:09, Amit Langote wrote:
> > Should the following paragraph in src/backend/optimizer/README be
> > updated to reflect the new reality after recent changes?
> >
> > An EquivalenceCla
lifies as a bug, I’d lean toward “no” -- at
least in the sense that it doesn’t produce incorrect results. We’ve
historically treated unsupported pruning cases like this as missed
optimization opportunities rather than planner correctness issues.
That would argue against backpatching a fix, even if we do decide to
improve the pruning logic in this area and for other cases going
forward.
--
Thanks, Amit Langote
On Thu, Apr 10, 2025 at 2:35 PM David Rowley wrote:
> On Thu, 10 Apr 2025 at 16:57, Amit Langote wrote:
> >
> > On Thu, Apr 10, 2025 at 12:03 PM David Rowley wrote:
> > > -Most operations on EquivalenceClasses should ignore child members.
> > > +Most operati
. See 17958972fe3b which added
the comment, especially the test cases that it adds.
--
Thanks, Amit Langote
On Thu, Apr 10, 2025 at 12:03 PM David Rowley wrote:
> On Wed, 9 Apr 2025 at 17:38, Amit Langote wrote:
> > Still, maybe a tiny tweak to the last line could help steer readers
> > right without diving into storage. How about:
> >
> > Most operations on Equivalence
child-relation expressions to EquivalenceClasses.
Most operations on EquivalenceClasses should ignore child members.
The part about these being in the EquivalenceClass might be worth
rewording now that we keep them in a separate array.
--
Thanks, Amit Langote
y. So I rewrote it as:
+ * We do not attempt a second lookup with EMs swapped, because the key is
+ * canonicalized during both insertion and lookup.
0003’s commit message includes a blurb I plan to paste into the main
patch’s message (with minor tweaks) when we squash the patches.
--
Thanks, Amit Langote
v6-0003-Canonicalize-keys-for-derived-clause-hash-table.patch
Description: Binary data
v6-0001-Add-assertion-to-verify-derived-clause-has-consta.patch
Description: Binary data
v6-0002-Make-derived-clause-lookup-in-EquivalenceClass-mo.patch
Description: Binary data
On Fri, Apr 4, 2025 at 5:48 PM Ashutosh Bapat
wrote:
> On Fri, Apr 4, 2025 at 2:04 PM Amit Langote wrote:
> > I’ve now marked this as committed after pushing the patches earlier today.
>
> Thanks a lot.
Thank you too for working on it.
> > I realize the CF entry was
ression
* for an appendrel child.
...
+/* XXX ec_childmembers? */
Maybe we don’t need to print these, since the comment on em_is_child
suggests they aren’t really full-fledged EC members and are meant to
be ignored by most operations?
--
Thanks, Amit Langote
On Thu, Apr 3, 2025 at 12:28 PM Amit Langote wrote:
> On Wed, Apr 2, 2025 at 9:52 PM Ashutosh Bapat
> wrote:
> > On Wed, Apr 2, 2025 at 1:00 PM Amit Langote wrote:
> > > I'm feeling good about this version, but let me know if you have any
> > > further thou
On Fri, Dec 20, 2024 at 1:23 PM Amit Langote wrote:
> We discussed $subject at [1] and [2] and I'd like to continue that
> work with the hope to commit some part of it for v18.
I did not get a chance to do any further work on this in this cycle,
but plan to start working on it after b
On Wed, Apr 2, 2025 at 9:52 PM Ashutosh Bapat
wrote:
> On Wed, Apr 2, 2025 at 1:00 PM Amit Langote wrote:
> > I'm feeling good about this version, but let me know if you have any
> > further thoughts / comments.
>
> Thanks for incorporating the changes and fixi
On Wed, Apr 2, 2025 at 1:58 AM Ashutosh Bapat
wrote:
> On Tue, Apr 1, 2025 at 1:32 PM Amit Langote wrote:
> >
> > I think David’s suggestion to use 64 as the fixed initial size is
> > simpler and more predictable. Since list_length * 2 will always be >=
> > 64 a
On Tue, Mar 25, 2025 at 6:36 PM Ashutosh Bapat
wrote:
> On Tue, Mar 25, 2025 at 12:58 PM Amit Langote wrote:
> > Btw, about ec_clear_derived_clauses():
> >
> > @@ -749,7 +749,7 @@ remove_rel_from_eclass(EquivalenceClass *ec,
> > SpecialJoinInfo *sjinfo,
> >
On Tue, Mar 25, 2025 at 3:17 PM Ashutosh Bapat
wrote:
> On Mon, Mar 24, 2025 at 7:23 PM Amit Langote wrote:
> >
> > Ok, thanks for that analysis. I don't think there's anything about
> > the patch that makes it particularly less suitable for pwj=on.
> >
&g
On Wed, Mar 19, 2025 at 3:31 PM Ashutosh Bapat
wrote:
> On Wed, Mar 19, 2025 at 8:22 AM Amit Langote wrote:
> > Yes, those were with pwj=off. FTR, numbers I get with pwj=on.
> >
> > 3-way:
> >
> > nparts master patched %change
> > 0
On Tue, Mar 18, 2025 at 8:48 PM Ashutosh Bapat
wrote:
> On Tue, Mar 18, 2025 at 4:02 PM Amit Langote wrote:
> >
> > I ran a couple of benchmarks of my own as follows.
> >
> > cat benchmark_amit.sh
> > for p in 0 16 32 64 128 256 512 1024; do
> > echo -n
On Mon, Mar 17, 2025 at 5:47 PM Ashutosh Bapat
wrote:
> On Fri, Mar 14, 2025 at 5:36 PM Amit Langote wrote:
> > Thanks for the patch and the extensive benchmarking.
> >
> > Would you please also share a simple, self-contained example that I
> > can use to reproduce
y was used to produce the numbers in the report.
Btw, in the commit message, you mention:
===
When there are thousands of partitions in a partitioned table, there
can be thousands of derived clauses in the list making it inefficient
for a lookup.
===
I haven’t found a description of how that many clauses end up in the
ec->ec_derived list. IIUC, it's create_join_clause() where the child
clauses get added, and it would be helpful to mention that, since that
also appears to be the hotspot your patch is addressing.
> I think the first patch in the attached set is worth committing, just
> to tighten things up.
I agree and am happy to commit it if there are no objections.
--
Thanks, Amit Langote
Hi Nikita,
I was looking at the patch you posted on Feb 3. Two high-level comments:
* The documentation additions are missing.
* It looks like the patch mixes refactoring changes with new
functionality, which makes it harder to follow what's existing vs.
new. Could you separate these changes so
On Wed, Mar 12, 2025 at 21:40 Álvaro Herrera
wrote:
> On 2025-Mar-12, Amit Langote wrote:
>
> > Patch look good for committing?
>
> Ah sorry, I should have said so -- yes, it looks good to me.
Thanks (Maciek, Tender too) for the review.
I feel a
> slight dislike
On Wed, Mar 12, 2025 at 7:09 PM Álvaro Herrera wrote:
> On 2025-Mar-12, Amit Langote wrote:
>
> > I was able to construct a test case that crashes due to this bug:
> >
> > CREATE TYPE mood AS ENUM ('happy', 'sad', 'neutral');
> > CREATE
On Wed, Mar 12, 2025 at 12:07 PM Amit Langote wrote:
> On Wed, Mar 12, 2025 at 10:00 AM Tender Wang wrote:
> > Maciek Sakrejda 于2025年3月11日周二 08:12写道：
> >> While exploring the jsonb code, I noticed that in
> >> datum_to_jsonb_internal, the tcategory checks compares
quot; turned into "JSONTYPE_JSON". Should that have
>> been "JSONTYPE_CAST" (that seems to be the corresponding value in the
>> new enum) instead?
>
> The below else branch has code if (tcategory == JSONTYPE_CAST). I guess here
> the
> second JSONTYPE_JSON may just be removed.
> @Amit Langote please check out this.
Looks like a copy-paste bug on my part. Will fix, thanks for the report.
--
Thanks, Amit Langote
++ b/src/backend/rewrite/rewriteHandler.c
@@ -174,6 +174,7 @@ AcquireRewriteLocks(Query *parsetree,
switch (rte->rtekind)
{
case RTE_RELATION:
+case RTE_GRAPH_TABLE:
--
Thanks, Amit Langote
On Sun, Feb 23, 2025 at 9:46 PM Tender Wang wrote:
> Amit Langote 于2025年2月23日周日 16:36写道：
>> On Sun, Feb 23, 2025 at 2:03 AM Tender Wang wrote:
>> > Alexander Lakhin 于2025年2月22日周六 23:00写道：
>> >> Please look at new error, produced by the following script,
On Sun, Feb 23, 2025 at 2:03 AM Tender Wang wrote:
> Alexander Lakhin 于2025年2月22日周六 23:00写道：
>> 21.02.2025 05:40, Amit Langote wrote:
>>
>> I pushed the final piece yesterday.
>>
>>
>> Please look at new error, produced by the following script,
>>
On Sat, Feb 22, 2025 at 11:13 AM Amit Langote wrote:
> On Sat, Feb 22, 2025 at 12:55 AM Tom Lane wrote:
> > Amit Langote writes:
> > > The short of it is that the cached-plan-inval test in the
> > > delay_execution suite can never be made to work under
> >
On Sat, Feb 22, 2025 at 12:55 AM Tom Lane wrote:
> Amit Langote writes:
> > The short of it is that the cached-plan-inval test in the
> > delay_execution suite can never be made to work under
> > CLOBBER_CACHE_ALWAYS. The test assumes that locks on partitions for a
> &
On Fri, Feb 21, 2025 at 3:36 PM Amit Langote wrote:
> On Fri, Feb 21, 2025 at 3:04 PM Tom Lane wrote:
> >
> > Amit Langote writes:
> > > I pushed the final piece yesterday.
> >
> > trilobite reports that this fails under -DCLOBBER_CACHE_ALWAYS:
> >
&g
On Fri, Feb 21, 2025 at 3:04 PM Tom Lane wrote:
>
> Amit Langote writes:
> > I pushed the final piece yesterday.
>
> trilobite reports that this fails under -DCLOBBER_CACHE_ALWAYS:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=trilobite&dt=2025-02-20%201
On Wed, Feb 12, 2025 at 8:53 PM Amit Langote wrote:
> On Thu, Feb 6, 2025 at 11:35 AM Amit Langote wrote:
> > Per cfbot-ci, the new test case output in 0002 needed to be updated.
> >
> > I plan to push 0001 tomorrow, barring any objections.
>
> I pushed that last Frid
Hi Junwang,
On Sun, Feb 16, 2025 at 1:37 PM Junwang Zhao wrote:
> On Sat, Feb 15, 2025 at 3:51 PM Amit Langote wrote:
> > Thanks! It looks like I missed updating the MERGE-related lists in
> > ModifyTable.
> >
> > I've attached a fix with a test added based on
Hi Alexander,
On Sat, Feb 15, 2025 at 6:00 AM Alexander Lakhin wrote:
>
> Hello Amit,
>
> 06.02.2025 04:35, Amit Langote wrote:
>
> I plan to push 0001 tomorrow, barring any objections.
>
>
> Please try the following script:
> CREATE TABLE pt (a int, b int) PARTITIO
On Thu, Feb 6, 2025 at 11:35 AM Amit Langote wrote:
> Per cfbot-ci, the new test case output in 0002 needed to be updated.
>
> I plan to push 0001 tomorrow, barring any objections.
I pushed that last Friday. With bb3ec16e, d47cbf47, and cbc12791 now in:
* Pruning information is n
Hi Nikita,
On Wed, Dec 18, 2024 at 12:11 AM Nikita Malakhov wrote:
>
> Hi hackers!
>
> This thread is further work continued in [1], where Amit Langote
> suggested starting discussion on the remaining SQL/JSON feature
> 'PLAN clause for JSON_TABLE' anew.
>
>
t here either.
>
> Pushed.
Sorry Alvaro for not noticing sooner.
I looked at db19a5061ce and it all looks fine to me.
--
Thanks, Amit Langote
On Fri, Jan 17, 2025 at 2:05 PM Amit Langote wrote:
> Here's v5 with a few commit message tweaks.
>
> Barring objections, I would like to push this early next week.
Pushed yesterday. Thank you all.
--
Thanks, Amit Langote
Here's v5 with a few commit message tweaks.
Barring objections, I would like to push this early next week.
--
Thanks, Amit Langote
v5-0001-Refactor-ExecScan-to-allow-inlining-of-its-core-l.patch
Description: Binary data
Hi Junwang,
On Sat, Jan 11, 2025 at 7:39 PM Junwang Zhao wrote:
> Hi Amit,
>
> On Fri, Jan 10, 2025 at 7:22 PM Amit Langote wrote:
> >
> > On Fri, Jan 10, 2025 at 7:36 PM David Rowley wrote:
> > > On Fri, 10 Jan 2025 at 22:53, Vladlen Popolitov
> >
Hi Vladlen,
On Fri, Jan 10, 2025 at 11:49 PM Vladlen Popolitov
wrote:
> Amit Langote писал(а) 2025-01-10 18:22:
> > On Fri, Jan 10, 2025 at 7:36 PM David Rowley
> > wrote:
> >> On Fri, 10 Jan 2025 at 22:53, Vladlen Popolitov
> >> wrote:
> >> >
.
Vladlen, does what David wrote and the new commit message answer your
question(s)?
--
Thanks, Amit Langote
v4-0001-Refactor-ExecScan-to-inline-scan-filtering-and-pr.patch
Description: Binary data
On Fri, Jan 10, 2025 at 1:06 PM David Rowley wrote:
> On Fri, 10 Jan 2025 at 02:46, Amit Langote wrote:
> >
> > On Mon, Jan 6, 2025 at 10:18 PM David Rowley wrote:
> > > I've attached my workings of what I was messing around with. It seems
> > > to per
On Mon, Jan 6, 2025 at 10:18 PM David Rowley wrote:
> On Sat, 21 Dec 2024 at 00:41, Amit Langote wrote:
> > To address (1), I tried assigning specialized functions to
> > PlanState.ExecProcNode in ExecInitSeqScan() based on whether qual or
> > projInfo are NULL. Inspi
latency of queries of shape
`SELECT agg(somecol or *) FROM big_table WHERE ` generally
faster with up to 5% improvement in some cases.
Would love to hear thoughts.
--
Thanks, Amit Langote
[1]
https://docs.google.com/spreadsheets/d/1AsJOUgIfSsYIJUJwbXk4aO9FVOFOrBCvrfmdQYkHIw4/edit?usp=sharing
v1
the checks causes them to fail, as
expected. This behavior is maintained because permission checks are
performed during each execution. The planned changes to separate the
"plan" and "execute" steps should continue to uphold this and other
behaviors that might need to be pres
Hi Rahila,
Thanks for working on this. I've wanted something like this a number
of times to replace my current method of attaching gdb like everyone
else I suppose.
I have a question / suggestion about the interface.
+Datum
+pg_get_process_memory_contexts(PG_FUNCTION_ARGS)
+{
+int p
AIL: Types json and jsonb are allowed in RETURNING.
I think I'd go with the one you chose.
Are you planning to push a fix yourself or would you like me to?
--
Thanks, Amit Langote
On Fri, Dec 6, 2024 at 5:18 PM Amit Langote wrote:
> On Thu, Dec 5, 2024 at 11:07 PM Tomas Vondra wrote:
> > On 12/5/24 12:28, Amit Langote wrote:
> > > On Thu, Dec 5, 2024 at 3:53 PM Amit Langote
> > > wrote:
> > >> On Thu, Dec 5, 2024 at 2:20 AM Toma
On Thu, Dec 5, 2024 at 10:53 PM Tomas Vondra wrote:
> On 12/5/24 07:53, Amit Langote wrote:
> > On Thu, Dec 5, 2024 at 2:20 AM Tomas Vondra wrote:
> >> ...
> >>
> >>>> What if an
> >>>> extension doesn't do that? What weirdness wi
On Thu, Dec 5, 2024 at 11:07 PM Tomas Vondra wrote:
> On 12/5/24 12:28, Amit Langote wrote:
> > On Thu, Dec 5, 2024 at 3:53 PM Amit Langote wrote:
> >> On Thu, Dec 5, 2024 at 2:20 AM Tomas Vondra wrote:
> >>> Sure, changing the APIs is allowed, I'm just wonder
On Thu, Dec 5, 2024 at 3:53 PM Amit Langote wrote:
> On Thu, Dec 5, 2024 at 2:20 AM Tomas Vondra wrote:
> > Sure, changing the APIs is allowed, I'm just wondering if maybe there
> > might be a way to not have this issue, or at least notice the missing
> > call earl
On Thu, Dec 5, 2024 at 2:20 AM Tomas Vondra wrote:
> On 12/4/24 14:34, Amit Langote wrote:
> > On Mon, Dec 2, 2024 at 3:36 AM Tomas Vondra wrote:
> >> 0001
> >>
> >>
> >> 1) But if we don't expect this error to actually happen, do we really
ssert is sufficient here. An
Append/MergeAppend node's part_prune_index not pointing to the correct
entry in the global "flat" list of PartitionPruneInfos would indicate
a bug. It seems unlikely that user actions could cause this issue.
--
Thanks, Amit Langote
ans. Is that correct, or do I understand this wrong?
That's correct. The planner does not consider runtime pruning when
assigning costs to Append or MergeAppend paths in
create_{merge}append_path().
> Just to be clear, I'm not claiming the patch has to deal with this. I
> suppose it can be handled as a future improvement, and I'm not even sure
> there's a good way to consider this during costing. For example, can we
> estimate how many partitions will be pruned?
There have been discussions about this in the 2017 development thread
of run-time pruning [1] and likely at some later point in other
threads. One simple approach mentioned at [1] is to consider that
only 1 partition will be scanned for queries containing WHERE partkey
= $1, because only 1 partition can contain matching rows with that
condition.
I agree that this should be dealt with sooner than later so users get
generic plans even without having to use force_generic_plan.
I'll post the updated patches tomorrow.
--
Thanks, Amit Langote
[1]
https://www.postgresql.org/message-id/CA%2BTgmoZv8sd9cKyYtHwmd_13%2BBAjkVKo%3DECe7G98tBK5Ejwatw%40mail.gmail.com
On Wed, Nov 27, 2024 at 12:53 AM Alvaro Herrera wrote:
> On 2024-Nov-20, Amit Langote wrote:
> > On Tue, Nov 19, 2024 at 6:41 PM Alvaro Herrera
> > wrote:
>
> > Here's an example that I think matches the above description, which,
> > ISTM, leads to a state
On Tue, Nov 19, 2024 at 6:41 PM Alvaro Herrera wrote:
> On 2024-Nov-14, Amit Langote wrote:
>
> > Sorry, here's the full example. Note I'd changed both
> > AddRelationNotNullConstraints() and AdjustNotNullInheritance() to not
> > throw an error *if* the tab
On Wed, Nov 13, 2024 at 10:49 PM Alvaro Herrera wrote:
> On 2024-Nov-13, Amit Langote wrote:
>
> > I rebased my patch over 14e87ffa5c54 and noticed that NOT NULL
> > constraints can also (or not) be marked NO INHERIT. I think we should
> > allow NO INHERIT NOT NULL constr
On Tue, Nov 12, 2024 at 5:46 PM Alvaro Herrera wrote:
> On 2024-Nov-11, Amit Langote wrote:
>
> > The restriction also exists in the CREATE TABLE PARTITION OF path:
> >
> > [...]
> >
> > I think we can remove the restriction at least for the leaf partit
e to smgr from being
* invalidated. SMgrRelations that are not pinned are deleted at end of
--
Thanks, Amit Langote
v1-0001-Add-missing-word-in-comment.patch
Description: Binary data
On Fri, Nov 8, 2024 at 2:54 AM Alvaro Herrera wrote:
> On 2024-Nov-07, Amit Langote wrote:
>
> > On Wed, Nov 6, 2024 at 9:34 PM Alvaro Herrera
> > wrote:
>
> > > Oh, hmm, that makes sense I guess. Still, while this restriction makes
> > > sense for inhe
ll try to make some time to review it in the January fest.
--
Thanks, Amit Langote
at by turning enable_hashagg on and off
to see the difference. Changing enable_partitionwise_aggregate for
either of the values of enable_hashagg didn't change the plan.
Thank you all for working on this.
--
Thanks, Amit Langote
On Wed, Nov 6, 2024 at 9:34 PM Alvaro Herrera wrote:
> On 2024-Nov-06, Amit Langote wrote:
> > On Tue, Nov 5, 2024 at 9:01 PM Alvaro Herrera
> > wrote:
> > > While doing final review for not-null constraints, I noticed that the
> > > ALTER TABLE
mit:
commit 3b11247aadf857bbcbfc765191273973d9ca9dd7
Author: Alvaro Herrera
Date: Mon Jan 16 19:19:42 2012 -0300
Disallow merging ONLY constraints in children tables
Perhaps the ATTACH PARTITION text should be changed to make clear
which case it's talking about, say, like:
If any of the CHECK constraints of the table being attached are marked
NO INHERIT, the command will fail if a constraint with the same name
exists in the parent table; such constraints must be recreated without
the NO INHERIT clause.
--
Thanks, Amit Langote
ion is case_insensitive, ORDER BY that column would
> render the output not deterministic.
> like 'A' before 'a' and 'a' before 'A' are both correct.
> it may cause regress tests to fail.
> So I did some minor refactoring to make the "ORDER BY" deterministic.
Thanks, merged.
--
Thanks, Amit Langote
v6-0002-Disallow-partitionwise-join-when-collation-doesn-.patch
Description: Binary data
v6-0001-Disallow-partitionwise-grouping-when-collation-do.patch
Description: Binary data
Hi,
On Fri, Nov 1, 2024 at 2:39 PM jian he wrote:
> On Thu, Oct 31, 2024 at 9:09 PM Amit Langote wrote:
> >
> >
> > I think we should insist that the join key collation and the partition
> > collation are exactly the same and refuse to mat
1 - 100 of 1465 matches
Mail list logo
