On Wed, 2020-09-30 at 16:27 +0900, Michael Paquier wrote:
> On Fri, Sep 04, 2020 at 01:59:47PM +0200, Laurenz Albe wrote:
> > I'll set the commitfest entry to "waiting for author".
>
> This review, as well as any of the follow-up emails, have not been
> answered by the author, so I have marked the
On Fri, Sep 04, 2020 at 01:59:47PM +0200, Laurenz Albe wrote:
> I'll set the commitfest entry to "waiting for author".
This review, as well as any of the follow-up emails, have not been
answered by the author, so I have marked the patch as returned with
feedback.
--
Michael
signature.asc
Descrip
On 2020-Sep-08, Laurenz Albe wrote:
> We should at least have
>
> ALTER TABLE ... ADD PRIMARY KEY (id) INCLUDE (val);
>
> or something before we consider this patch.
Agreed.
Now the trick in this new command is to let the user change the included
columns afterwards, which remains useful (sin
On Mon, 2020-09-07 at 11:42 -0300, Alvaro Herrera wrote:
> > This patch would provide a more convenient way to do that.
> > Again, I am not sure if that justifies the effort.
>
> I have to admit I've seen cases where it'd be useful to have included
> columns in primary keys.
>
> TBH I think if we
On 2020-Sep-07, Laurenz Albe wrote:
> This patch would provide a more convenient way to do that.
>
> Again, I am not sure if that justifies the effort.
I have to admit I've seen cases where it'd be useful to have included
columns in primary keys.
TBH I think if we really wanted the feature of p
On Fri, 2020-09-04 at 13:31 -0400, Alvaro Herrera wrote:
> On 2020-Sep-04, Laurenz Albe wrote:
> > On Fri, 2020-09-04 at 10:41 -0400, Alvaro Herrera wrote:
> > > > The value I see in this is:
> > > > - replacing a primary key index
> > > > - replacing the index behind a constraint targeted by a for
On 2020-Sep-04, Laurenz Albe wrote:
> On Fri, 2020-09-04 at 10:41 -0400, Alvaro Herrera wrote:
> > > The value I see in this is:
> > > - replacing a primary key index
> > > - replacing the index behind a constraint targeted by a foreign key
> >
> > But why is this better than using REINDEX CONCUR
On Fri, 2020-09-04 at 10:41 -0400, Alvaro Herrera wrote:
> > The value I see in this is:
> > - replacing a primary key index
> > - replacing the index behind a constraint targeted by a foreign key
>
> But why is this better than using REINDEX CONCURRENTLY?
It is not better, but it can be used to
On 2020-Sep-04, Laurenz Albe wrote:
> The value I see in this is:
> - replacing a primary key index
> - replacing the index behind a constraint targeted by a foreign key
But why is this better than using REINDEX CONCURRENTLY?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
Postgre
On Mon, 2020-08-10 at 09:29 +0300, Anna Akenteva wrote:
> On 2020-07-07 01:08, Tom Lane wrote:
>
> > Alvaro Herrera writes:
> > > On 2020-Jul-05, Anna Akenteva wrote:
> > > > -- Swapping primary key's index for an equivalent index,
> > > > -- but with INCLUDE-d attributes.
> > > > CREATE UNIQUE I
On 2020-07-07 01:08, Tom Lane wrote:
Alvaro Herrera writes:
On 2020-Jul-05, Anna Akenteva wrote:
-- Swapping primary key's index for an equivalent index,
-- but with INCLUDE-d attributes.
CREATE UNIQUE INDEX new_idx ON target_tbl (id) INCLUDE (info);
ALTER TABLE target_tbl ALTER CONSTRAINT tar
Alvaro Herrera writes:
> On 2020-Jul-05, Anna Akenteva wrote:
>> -- Swapping primary key's index for an equivalent index,
>> -- but with INCLUDE-d attributes.
>> CREATE UNIQUE INDEX new_idx ON target_tbl (id) INCLUDE (info);
>> ALTER TABLE target_tbl ALTER CONSTRAINT target_tbl_pkey USING INDEX
>>
On 2020-Jul-05, Anna Akenteva wrote:
> -- Swapping primary key's index for an equivalent index,
> -- but with INCLUDE-d attributes.
> CREATE UNIQUE INDEX new_idx ON target_tbl (id) INCLUDE (info);
> ALTER TABLE target_tbl ALTER CONSTRAINT target_tbl_pkey USING INDEX
> new_idx;
> ALTER TABLE refere
13 matches
Mail list logo
