Hi Ashutosh!
On 2024-05-27 14:17, Ashutosh Bapat wrote:
On Fri, May 24, 2024 at 11:02 AM wrote:
Hi Ashutosh,
thanks for bringing this to my attention. I'll first share a few
thoughts about the change and respond regarding the test below.
I clearly understand your intention with this patch.
Hi Ashutosh,
thanks for bringing this to my attention. I'll first share a few
thoughts about the change and respond regarding the test below.
I clearly understand your intention with this patch. It's an issue I run
into from time to time.
I did some testing with some benchmark sets back
.
Regards
Arne
On 2024-01-22 19:22, Tom Lane wrote:
Arne Roland writes:
Thank you for bringing that to my attention. Is there a way to subscribe
to cf-bot failures?
I don't know of any push notification support in cfbot, but you
can bookmark the page with your own active patches, and check
Thank you for bringing that to my attention. Is there a way to subscribe
to cf-bot failures?
Apparently I confused myself with my naming. I attached a patch that
fixes the bug (at least at my cassert test-world run).
Regards
Arne
On 2024-01-22 06:38, Peter Smith wrote:
2024-01 Commitfest.
Hi Richard,
I can tell this a real world problem. I have seen this multiple times in
production.
The fix seems surprisingly simple.
I hope my questions here aren't completely off. I still struggle to
think about the implications.
I wonder, if there is any stuff we are breaking by bluntly
Hi!
Mikhail Gribkov writes:
> > Honestly I'm not entirely sure fixing only two switched words is
worth the
> > effort, but the declared goal is clearly achieved.
>
>
> > I think the patch is good to go, although you need to fix code
formatting.
>
>
> I took a brief look at this. I concur
Hello Mikhail,
I'm sorry. Please try attached patch instead.
Thank you for having a look!
Regards
Arne
From: Mikhail Gribkov
Sent: Thursday, July 6, 2023 13:31
To: Arne Roland
Cc: Pg Hackers
Subject: Re: Permute underscore separated components of columns
Thank you! I just tried our benchmark and got a performance degration of around
28 %, which is way better than the last patch.
The simple query select * from generate_series(0, 1000) shows roughly 18.9
% degradation on my test server.
By raising initial_allocation_allowance and
of it as a quality of life thing.
Let me know what you think. Thank you!
Regards
Arne
From 2f5801abe48234fade70a7238fe2a1d1f2c5813d Mon Sep 17 00:00:00 2001
From: Arne Roland
Date: Fri, 6 Jan 2023 22:23:37 +0100
Subject: [PATCH] fuzzy_underscore_permutation
---
src/backend/parser/parse_relation.c | 103
Freund
Sent: Tuesday, November 22, 2022 2:36:59 AM
To: Arne Roland
Cc: David Rowley; Amit Langote; pgsql-hackers; Zhihong Yu; Alvaro Herrera;
Julien Rouhaud
Subject: Re: missing indexes in indexlist with partitioned tables
Hi,
On 2022-11-02 01:50:38 +, Arne Roland wrote:
> I mainly chan
Hi!
I mainly changed the comments, the Assert and some casing.
> From: David Rowley
> Sent: Monday, October 3, 2022 00:51
>
> * In the header comment in get_relation_info(), I don't think we need
> to mention join removals explicitly. At a stretch, maybe mentioning
> "unique proofs" might be
Hello Reid,
could you rebase the patch again? It doesn't apply currently
(http://cfbot.cputube.org/patch_40_3867.log). Thanks!
You mention, that you want to prevent the compiler from getting cute.
I don't think this comments are exactly helpful in the current state. I think
probably fine to
appreciated!
Regards
Arne
From 290252bab5837c1a6f42bd53cf788c8696d5d0ec Mon Sep 17 00:00:00 2001
From: Arne Roland
Date: Sat, 1 Oct 2022 18:14:34 +0200
Subject: [PATCH v8_indexlist_contains_partitioned_indexes] v8
---
src/backend/optimizer/util/plancat.c | 226 ++-
src/bac
Hi!
Attached a rebased version of the patch.
Regards
Arne
From: Arne Roland
Sent: Monday, January 31, 2022 19:14
To: Amit Langote
Cc: Zhihong Yu; Alvaro Herrera; Julien Rouhaud; pgsql-hackers
Subject: Re: missing indexes in indexlist with partitioned tables
Hi,
can someone point out to me, why we don't consider pushdowns of the joinqual
for these queries beyond the distinct on?
When the qual matches the distinct clause, it should be possible to generate
both parametrized and non parametrized subplans for the same query. The same
should hold
From: Jehan-Guillaume de Rorthais
Sent: Monday, March 21, 2022 11:36
Subject: Re: Detaching a partition with a FK on itself is not possible
> I changed the list destination
Thanks
> Another solution could be to teach the create partition to detect a self
> referencing FK and actually create a
Hi!
From: Amit Langote
Sent: Tuesday, January 25, 2022 09:04
Subject: Re: missing indexes in indexlist with partitioned tables
> [...]
> "partindexlist" really made me think about a list of "partial indexes"
> for some reason. I think maybe "partedindexlist" is what you are
> looking for;
Hi!
> From: Zhihong Yu
> Subject: Re: missing indexes in indexlist with partitioned tables
>
> Hi,
>
> - if (indexRelation->rd_rel->relkind == RELKIND_PARTITIONED_INDEX)
> + if (inhparent && (!index->indisunique ||
> indexRelation->rd_rel->relkind !=
added it
for potential future clarity.
Thanks for your feedback again!
Regards
Arne
From: Arne Roland
Sent: Wednesday, January 19, 2022 10:13:55 PM
To: Alvaro Herrera; Julien Rouhaud
Cc: pgsql-hackers
Subject: Re: missing indexes in indexlist with partitioned
Hi!
> From: Alvaro Herrera
> [...]
> Hmm, these plan changes look valid to me. A left self-join using the
> primary key column? That looks optimizable all right.
> [...]
> What I still don't know is whether this patch is actually desirable or
> not. If the only cases it affects is self-joins,
views make it almost
necessary to have it. If you had a different answer in mind, please don't
hesitate to ask again.
Regards
Arne
From: Alvaro Herrera
Sent: Monday, January 17, 2022 7:16:08 PM
To: Arne Roland
Cc: Julien Rouhaud; pgsql-hackers
Subject: Re
Using some valuable feedback from Zhihong Yu, I fixed a flipped negation error
and updated the comments.
Regards
Arne
From: Arne Roland
Sent: Monday, January 17, 2022 12:25
To: Julien Rouhaud
Cc: pgsql-hackers
Subject: Re: missing indexes in indexlist
Hi,
thank you for the heads up! Those files ended up accidentally in the dump from
me running pg_indent. The file count was truly excessive, I should have noticed
this sooner.
I attached the patch without the excessive modifications. That should be way
easier to read.
Regards
Arne
diff
Hi!
> From: Tomas Vondra
> Subject: Re: PATCH: generate fractional cheapest paths in
> generate_orderedappend_path
>
> test-# SELECT * FROM fract_t x LEFT JOIN fract_t y USING (id1, id2)
> ORDER BY id1 ASC, id2 ASC LIMIT 10;
>QUERY PLAN
>
>
Hi,
thanks for the reply!
From: Tomas Vondra
Sent: Thursday, December 2, 2021 20:58
Subject: Re: PATCH: generate fractional cheapest paths in
generate_orderedappend_path
> [...]
> Well, I mentioned three open questions in my first message, and I don't
> think we've really addressed them yet.
Arne
From: Arne Roland
Sent: Saturday, June 26, 2021 5:50:49 PM
To: Tomas Vondra
Cc: pgsql-hackers
Subject: Re: PATCH: generate fractional cheapest paths in
generate_orderedappend_path
Hi Tomas,
I don't think there is much work left to do here.
Did you have a look at the test cas
From: Justin Pryzby
Sent: Monday, November 29, 2021 16:10
> On Mon, Nov 29, 2021 at 02:01:35PM +0000, Arne Roland wrote:
> > But my main goal is something else. I can't explain my clients, why a
> > chanced statistics due to autovacuum suddenly leads to oom. They would be
> &
I did read parts of the last one back then. But thanks for the link, I plan to
reread the thread as a whole.
>From what I can tell, the discussions here are the attempt by very smart
>people to (at least partially) solve the problem of memory allocation (without
>sacrificing to much on the
Hello!
Since I used a lot of my time chasing short lived processes eating away big
chunks of memory in recent weeks, I am wondering about a decent way to go about
this.
The problem I am facing essentially relates to the fact that work_mem settings,
while they are enforced per hash and sort
Hi,
I stumbled across a few places that depend on the inheritance appends being
applied at a later date, so I quickly abandoned that idea. I thought a bit
about the indexlist, in particular the inhparent, and I am not sure what
depends on get_relation_info working in that way.
Therefore I
Hi,
I did a bit of testing today and noticed that we don't set indexlist properly
at the right time in some cases when using partitioned tables.
I attached a simple case where the indexlist doesn't seems to be set at the
right time. get_relation_info in plancat.c seems to process it only
From: Tom Lane
Sent: Monday, July 26, 2021 19:38
To: Alvaro Herrera
Subject: Re: Rename of triggers for partitioned tables
> Yeah, we don't support partial indexes on catalogs, and this example
> doesn't make me feel like we ought to open that can of worms.
I asked why such an index doesn't
From: Alvaro Herrera
Sent: Thursday, July 22, 2021 19:33
To: Arne Roland
Subject: Re: Rename of triggers for partitioned tables
On 2021-Jul-22, Arne Roland wrote:
> Since it is sort of the same problem, I think it might be worthwhile
> to address it as well within this patch. Adding two t
From: Alvaro Herrera
Sent: Thursday, July 22, 2021 18:20
To: Arne Roland
Subject: Re: Rename of triggers for partitioned tables
If we have good use for such an index, I don't see why we can't add it.
But I'm not sure that it is justified -- certainly if the only benefit
is to make ALTER TRIGGER
, tgrelid), which sounds
like a decent sanity check to have anyways.
From: Alvaro Herrera
Sent: Thursday, July 22, 2021 00:16
To: Arne Roland
Cc: vignesh C; Zhihong Yu; Pg Hackers
Subject: Re: Rename of triggers for partitioned tables
... now, thinking about how
Thank you! I get a compile time error
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement
-Werror=vla -Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3
-Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard
-Wno-format-truncation
> We are referring the trigger via it's name after all. If a child is named
> differently we break with that assumption. I think informing the user about
> that, is very valuable.
To elaborate on that:
While we to similar things for things like set schema, here it has a functional
relevance.
Hi!
From: Alvaro Herrera
Sent: Tuesday, July 20, 2021 02:03
To: Arne Roland
Cc: vignesh C; Zhihong Yu; Pg Hackers
Subject: Re: Rename of triggers for partitioned tables
I found this coding too convoluted, so I rewrote it in a different way.
You tests pass with this, but I admit I haven't
Hello Vignesh,
thank you for your interest!
From: vignesh C
Sent: Thursday, July 15, 2021 14:08
To: Arne Roland
Cc: Zhihong Yu; Alvaro Herrera; Pg Hackers
Subject: Re: Rename of triggers for partitioned tables
> The patch does not apply on Head anymore, could you rebase and post a
> patc
Hi!
From: Zhihong Yu
Sent: Saturday, June 26, 2021 20:32
Subject: Re: Rename of triggers for partitioned tables
> Hi, Arne:
> It seems the patch no longer applies cleanly on master branch.
> Do you mind updating the patch ?
>
> Thanks
Thank you for having a look! Please let me know if the
From: Alvaro Herrera
Sent: Saturday, June 26, 2021 18:36
Subject: Re: Rename of triggers for partitioned tables
> I'll have a look during the commitfest which starts late next week.
Thank you!
> (However, I'm fairly sure that it won't be in released versions ...
> it'll only be fixed in the
Hello Álvaro Herrera,
I am sorry to bother, but I am still annoyed by this. So I wonder if you had a
look.
Regards
Arne
From: Arne Roland
Sent: Friday, April 2, 2021 7:55:16 PM
To: Alvaro Herrera
Cc: David Steele; Pg Hackers
Subject: Re: Rename of triggers
Hi Tomas,
I don't think there is much work left to do here.
Did you have a look at the test case? Did it make sense to you?
And I am sorry. I had another look at this and it seems I was confused (again).
From: Arne Roland
Sent: Monday, April 26, 2021 13:00
To: Tomas Vondra; pgsql-hackers
Hi,
thanks for the quick reply!
From: Tomas Vondra
Sent: Thursday, June 3, 2021 20:11
To: Arne Roland; pgsql-hackers
Subject: Re: PATCH: generate fractional cheapest paths in
generate_orderedappend_path
> I haven't tested the parallel case, but I think we should sort out
Hi,
I haven't tested the parallel case, but I think we should sort out (3)
get_cheapest_fractional_path_for_pathkeys as mentioned above.
I am lost about the comment regarding startup_new_fractional. Could you
elaborate what you mean by that?
Apart from that, I'd argue for a small test
Hi,
thanks for looking into it!
For some reason the patch doesn't apply at my end, could you repost one based
at the master?
> 1) If get_cheapest_fractional_path_for_pathkeys returns NULL, it's not
> clear whether to default to cheapest_startup or cheapest_total. We might
> also consider an
didn't bother to much. They
only consist of basic sql tests.
Further feedback appreciated! Thank you!
Regards
Arne
From: Arne Roland
Sent: Thursday, April 1, 2021 4:38:59 PM
To: Alvaro Herrera
Cc: David Steele; Pg Hackers
Subject: Re: Rename of triggers
Alvaro Herrera wrote:
> I think the child cannot not have a corresponding trigger. If you try
> to drop the trigger on child, it should say that it cannot be dropped
> because the trigger on parent requires it. So I don't think there's any
> case where altering name of trigger in parent would
Thank you for the quick reply!
Alvaro Herrera wrote:
> I think this is not what we want to do. What you're doing here as I
> understand is traversing the inheritance hierarchy down using the
> trigger name, and then fail if the trigger with that name has a
> different parent or if no trigger
Attached a rebased patch with the suggested "ONLY ON" change.
Regards
Arne
____
From: Arne Roland
Sent: Monday, March 29, 2021 9:37:53 AM
To: David Steele; Alvaro Herrera
Cc: Pg Hackers
Subject: Re: Rename of triggers for partitioned tables
David St
David Steele wrote:
> Arne, thoughts on Álvaro's comments?
>
> Marking this patch as Waiting for Author.
Thank you for the reminder. I was to absorbed by other tasks. I should be more
present in the upcoming weeks.
> I think you did not register the patch in commitfest, so I did that for
> you:
While I'd agree that simply deleting with "on delete cascade" on tuple
rerouting is a strong enough violation of the spirit of partitioning changing
that behavior, I am surprised by the idea to make a differentiation between fks
and other triggers. The way user defined triggers work, is a
whether the tuple is removed or only rerouted.
Regards
Arne
From: Amit Langote
Sent: Tuesday, December 15, 2020 4:45:19 AM
To: Arne Roland
Cc: Tomas Vondra; David G. Johnston; PostgreSQL-development
Subject: Re: a misbehavior of partition row movement (?)
On Tue
Hi,
thanks for looking into this. I haven't yet looked at your patch in detail, yet
I think we should address the general issue here. To me this doesn't seem to be
a RI-trigger issue, but a more general issue like I mentioned in the pg-bugs
thread
I'm sorry for the spam. Here a patch with updated comments, I missed one before.
Regards
Arne
From: Arne Roland
Sent: Friday, November 27, 2020 1:05:02 AM
To: Pg Hackers
Subject: Re: Rename of triggers for partitioned tables
I'm too unhappy
I'm too unhappy with the interface change, so please view attached patch
instead.
Regards
Arne
From: Arne Roland
Sent: Friday, November 27, 2020 12:28:31 AM
To: Pg Hackers
Subject: Rename of triggers for partitioned tables
Hello,
I got too annoyed
Hello,
I got too annoyed at building queries for gexec all the time. So wrote a patch
to fix the issue that the rename of partitioned trigger doesn't affect children.
In case there isn't a dependent trigger with the same name on the child the
function errors out. If the user touched the
Richard Guo wrote:
> Please refer to the code snippet below:
>
> @@ -1164,8 +1164,8 @@ generate_join_implied_equalities(PlannerInfo *root,
> List *sublist = NIL;
>
> /* ECs containing consts do not need any further enforcement
> */
> if
nes which
happen before the restrict lists are generated?
Regards
Arne
From: Richard Guo
Sent: Thursday, August 1, 2019 1:14:44 PM
To: Arne Roland
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Partial join
On Thu, Aug 1, 2019 at 5:38 PM Arne Rol
, since we are left with multiple
partitions for both relations.
Regards
Arne
From: Tom Lane
Sent: Thursday, August 1, 2019 4:14:54 PM
To: Richard Guo
Cc: Arne Roland; pgsql-hackers@lists.postgresql.org
Subject: Re: Partial join
Richard Guo writes:
> For the
Hello,
I attached one example of a partitioned table with multi column partition key.
I also attached the output.
Disabling the hash_join is not really necessary, it just shows the more drastic
result in the case of low work_mem.
Comparing the first and the second query I was surprised to see
61 matches
Mail list logo
