Hi,
I found that thread (and the patch), but it seems to be pretty dead.
Patch didn't apply, due to gen_node_support.pl
Can I hope for a rebirth ?
I've made a rebased patch,in case of no response...
It's just the patch from
This thread has stalled since July with review comments unanswered, I'm marking
the patch Returned with Feedback. Please feel free to resubmit when/if a new
patch is available.
--
Daniel Gustafsson https://vmware.com/
On Tue, Jul 20, 2021 at 3:13 PM Justin Pryzby wrote:
> On Tue, Jul 20, 2021 at 02:42:16PM -0400, Robert Haas wrote:
> > The bigger issue IMHO with on-the-fly
> > partition creation is avoiding deadlocks in the presence of current
> > inserters; I submit that without at least some kind of attempt
On Tue, Jul 20, 2021 at 02:42:16PM -0400, Robert Haas wrote:
> The bigger issue IMHO with on-the-fly
> partition creation is avoiding deadlocks in the presence of current
> inserters; I submit that without at least some kind of attempt to
> avoid deadlocks and spurious errors there, it's not
On Wed, Jul 14, 2021 at 7:28 AM Pavel Borisov wrote:
> What do you think will the described approach lead to a useful patch? Should
> it be done as a whole or it's possible to commit it in smaller steps? (E.g.
> first part without AUTOMATIC capability, then add AUTOMATIC capability. Or
> with
>
> - I don't think it's a very good idea to support LIST and HASH but not
> RANGE. We need a design that can work for all three partitioning
> strategies, even if we don't have support for all of them in the
> initial patch. If they CAN all be in the same patch, so much the
> better.
>
> - I am
On Tue, Mar 2, 2021 at 3:26 PM Justin Pryzby wrote:
> I don't know what committers will say, but I think that "ALTER TABLE" might be
> the essential thing for this patch to support, not "CREATE". (This is similar
> to ALTER..SET STATISTICS, which is not allowed in CREATE.)
>
> The reason is that
>
> > Thank you for your review!
> > I've rebased the patch and made the changes mentioned.
> > PFA v5.
>
> I've set this back to "needs review" in CF.
>
Thanks for the attention! I did the review of this patch, and the changes
I've introduced in v5 are purely cosmetic. So I'd suppose the
On Fri, Jul 9, 2021 at 6:30 AM Pavel Borisov wrote:
> Thank you for your review!
> I've rebased the patch and made the changes mentioned.
> PFA v5.
I've set this back to "needs review" in CF.
--
John Naylor
EDB: http://www.enterprisedb.com
>
> I have reviewed the v4 patch. The patch does not get applied on the latest
> source. Kindly rebase.
> However I have found few comments.
>
> 1.
> > +-- must fail because of wrong configuration
> > +CREATE TABLE tbl_hash_fail (i int) PARTITION BY HASH (i)
> > +CONFIGURATION (values in (1, 2),
I have reviewed the v4 patch. The patch does not get applied on the latest
source. Kindly rebase.
However I have found few comments.
1.
> +-- must fail because of wrong configuration
> +CREATE TABLE tbl_hash_fail (i int) PARTITION BY HASH (i)
> +CONFIGURATION (values in (1, 2), (3, 4) default
https://commitfest.postgresql.org/32/2694/
I don't know what committers will say, but I think that "ALTER TABLE" might be
the essential thing for this patch to support, not "CREATE". (This is similar
to ALTER..SET STATISTICS, which is not allowed in CREATE.)
The reason is that ALTER is what's
>
> I don't think we can use \d+ on a temporary table here, because the
> backend ID appears in the namespace, which is causing a failure on one
> of the CI OSes due to nondeterminism:
>
> CREATE TEMP TABLE temp_parted (a char) PARTITION BY LIST (a)
> CONFIGURATION (VALUES IN ('a') DEFAULT
On Wed, Oct 7, 2020 at 6:26 AM Anastasia Lubennikova
wrote:
> Do you think that it is a bug? For now, I removed this statement from
> tests just to calm down the CI.
I don't think we can use \d+ on a temporary table here, because the
backend ID appears in the namespace, which is causing a
>
> My 0.02 €: What I think does not matter much, what committers think is the
> way to pass something. However, I do not think that such an idea would
> pass a committer:-)
>
The same idea was the reason for my proposal to make automatic partitioning
clauses to be in accordance with existing
Fabien, do you consider it possible to change the syntax of declarative
partitioning too?
My 0.02 €: What I think does not matter much, what committers think is the
way to pass something. However, I do not think that such an idea would
pass a committer:-)
It is problematic as it is
>
>
> > BTW could you tell me a couple of words about pros and cons of c-code
> > syntax parsing comparing to parsing using gram.y trees?
>
> I'd rather use an automatic tool (lexer/parser) if possible instead of
> doing it by hand if I can. If you want a really nice syntax with clever
> tricks,
BTW could you tell me a couple of words about pros and cons of c-code
syntax parsing comparing to parsing using gram.y trees?
I'd rather use an automatic tool (lexer/parser) if possible instead of
doing it by hand if I can. If you want a really nice syntax with clever
tricks, then you may
>
> Why? We could accept anything in the list? i.e.:
>
> (ident =? value[, ident =? value]*)
>
> > I don't against this but as far as I've heard there is some
> > opposition among PG community against new keywords. Maybe I am wrong.
>
> the ident is a keyword that can be interpreted later on,
HEllo.
CREATE TABLE foo(a int) PARTITION BY LIST(a) CONFIGURATION (FOR VALUES
IN
(1,2),(3,4) DEFAULT PARTITION foo_def);
I would like to disagree with this syntactic approach because it would
very specific to each partition method. IMHO the syntax should be as
generic as possible. I'd
>
> > CREATE TABLE foo(a int) PARTITION BY LIST(a) CONFIGURATION (FOR VALUES
> IN
> > (1,2),(3,4) DEFAULT PARTITION foo_def);
>
> I would like to disagree with this syntactic approach because it would
> very specific to each partition method. IMHO the syntax should be as
> generic as possible. I'd
CREATE TABLE foo(a int) PARTITION BY LIST(a) CONFIGURATION (FOR VALUES IN
(1,2),(3,4) DEFAULT PARTITION foo_def);
I would like to disagree with this syntactic approach because it would
very specific to each partition method. IMHO the syntax should be as
generic as possible. I'd suggest
On 2020-12-18 21:54, Pavel Borisov wrote:
I've realized one strange effect in current grammar parsing: if I do
CREATE TABLE foo (a int) PARTITION BY LIST (a) CONFIGURATION (a 1);
ERROR: unrecognized auto partition bound specification "a"
I consulted the patch code and realized that in fact,
I've realized one strange effect in current grammar parsing: if I do
CREATE TABLE foo (a int) PARTITION BY LIST (a) CONFIGURATION (a 1);
ERROR: unrecognized auto partition bound specification "a"
I consulted the patch code and realized that in fact, the patch considers
it the (invalid) HASH
Again I've checked v3 patch. In the discussion, there are several other
ideas on its further development, so I consider the patch as the first step
to later progress. Though now the patch is fully self-sufficient in
functionality and has enough tests etc. I suppose it is ready to be
committed.
--
>
>
> 2. One suggestion for generation of partition names is to append a
>> unique id to
>
> avoid conflicts.
>>
>> Can you please give an example of such a conflict? I agree that current
>> naming scheme is far from perfect, but I think that 'tablename'_partnum
>> provides unique name for
>
> Do you think that it is a bug? For now, I removed this statement from
> tests just to calm down the CI.
>
It is in accordance with changes in tests for vanilla
decralarive partitioning as per
commit 2dfa3fea88bc951d0812a18649d801f07964c9b9
Author: Tom Lane
Date: Mon Sep 28 13:44:01 2020
On 06.10.2020 00:21, Pavel Borisov wrote:
Hi, hackers!
I added some extra tests for different cases of use of automatic
partition creation.
v3-0002 can be applied on top of the original v2 patch for correct
work with some corner cases with constraints included in this test.
Thank you for
Hi, hackers!
I added some extra tests for different cases of use of automatic partition
creation.
v3-0002 can be applied on top of the original v2 patch for correct work
with some corner cases with constraints included in this test.
As for immediate/deferred I think that now only available now is
>
> Sorry for not being clear earlier, I mean the partition name
> 'tablename_partnum' can conflict with any existing table name.
> As per current impemetation, if I do the following it results in the table
> name conflict.
>
> postgres=# create table tbl_test_5_1(i int);
> CREATE TABLE
>
Hi,
Couple of comments:
> 1. The syntax used omits the { IMMEDIATE | DEFERRED} keywords suggested in
> the earlier discussions. I think it is intuitive to include IMMEDIATE with
> the current implementation
> so that the syntax can be extended with a DEFERRED clause in future for
> dynamic
On 30.09.2020 22:58, Rahila Syed wrote:
Hi Anastasia,
I tested the syntax with some basic commands and it works fine,
regression tests also pass.
Thank you for your review.
Couple of comments:
1. The syntax used omits the { IMMEDIATE | DEFERRED} keywords
suggested in
the earlier
Hi Anastasia,
I tested the syntax with some basic commands and it works fine, regression
tests also pass.
Couple of comments:
1. The syntax used omits the { IMMEDIATE | DEFERRED} keywords suggested in
the earlier discussions. I think it is intuitive to include IMMEDIATE with
the current
On 24.09.2020 06:27, Michael Paquier wrote:
On Mon, Sep 14, 2020 at 02:38:56PM +0300, Anastasia Lubennikova wrote:
Fixed. This was also caught by cfbot. This version should pass it clean.
Please note that regression tests are failing, because of 6b2c4e59.
--
Michael
Thank you. Updated patch
On Mon, Sep 14, 2020 at 02:38:56PM +0300, Anastasia Lubennikova wrote:
> Fixed. This was also caught by cfbot. This version should pass it clean.
Please note that regression tests are failing, because of 6b2c4e59.
--
Michael
signature.asc
Description: PGP signature
On 08.09.2020 17:03, Pavel Borisov wrote:
The patch lacks documentation, because I expect some details may
change during discussion. Other than that, the feature is ready
for review.
Hi, hackers!
From what I've read I see there is much interest in automatic
partitions creation.
> The patch lacks documentation, because I expect some details may change
> during discussion. Other than that, the feature is ready for review.
>
Hi, hackers!
>From what I've read I see there is much interest in automatic partitions
creation. (Overall discussion on the topic is partitioned into
On 14.07.2020 00:11, Anastasia Lubennikova wrote:
On 06.07.2020 13:45, Anastasia Lubennikova wrote:
The previous discussion of automatic partition creation [1] has
addressed static and dynamic creation of partitions and ended up with
several syntax proposals.
In this thread, I want to
38 matches
Mail list logo
