On Fri, Jun 7, 2019 at 2:35 PM Alvaro Herrera wrote:
> I envision this happening automatically -- you drop the partition, a
> persistent work item is registered, autovacuum takes care of it
> whenever. The user doesn't have to do anything about it.
We don't have to agree on anything now, but I t
On 2019-Jun-07, Peter Geoghegan wrote:
> On Fri, Jun 7, 2019 at 1:22 PM Alvaro Herrera
> wrote:
> > Because you can't rely on that exclusively, and you want to reuse the
> > partition ID eventually, you still need a cleanup process that removes
> > those remaining index entries. This cleanup p
On Fri, Jun 7, 2019 at 1:22 PM Alvaro Herrera wrote:
> Somehow we ended up discussing this topic in a rather mistitled thread
> ... oh well :-) (Nowadays I hesitate to change threads' subject lines,
> because gmail).
You can blame me for that, I think.
> > It occurs to me that we could add a co
Somehow we ended up discussing this topic in a rather mistitled thread
... oh well :-) (Nowadays I hesitate to change threads' subject lines,
because gmail).
On 2019-Jun-07, Peter Geoghegan wrote:
> On Fri, Jun 7, 2019 at 12:43 PM Alvaro Herrera
> wrote:
> > Well, "quickly" might mean within a
On Fri, Jun 7, 2019 at 12:43 PM Alvaro Herrera wrote:
> Well, "quickly" might mean within a week. If it takes that long to
> fully remove a monthly partition to make that partition ID available to
> some future month's partition, that seems acceptable. Blocking
> DROP/DETACH for one hour is cert
On 2019-Jun-07, Peter Geoghegan wrote:
> On Fri, Jun 7, 2019 at 12:18 PM Alvaro Herrera
> wrote:
> > I was thinking of asynchonously cleaning it up rather than blocking
> > DROP/DETACH ... which means you need to keep state somewhere. I don't
> > think blocking DROP/DETACH is valuable -- a glob
On Fri, Jun 7, 2019 at 12:18 PM Alvaro Herrera wrote:
> I was thinking of asynchonously cleaning it up rather than blocking
> DROP/DETACH ... which means you need to keep state somewhere. I don't
> think blocking DROP/DETACH is valuable -- a global index that blocks
> DROP/DETACH until the index
>
> I was thinking of asynchonously cleaning it up rather than blocking
> DROP/DETACH ... which means you need to keep state somewhere. I don't
> think blocking DROP/DETACH is valuable -- a global index that blocks
> DROP/DETACH until the index is clean serves no useful purpose. (You
> could thi
On 2019-Jun-07, Peter Geoghegan wrote:
> On Fri, Jun 7, 2019 at 9:10 AM Alvaro Herrera
> wrote:
> > I think vacuuming for global indexes is somewhat challenging as well :-)
> > Maybe not as much as for indirect indexes, that's true.
> >
> > In order for it to be sustainable, I think you'll want
On Fri, Jun 7, 2019 at 9:10 AM Alvaro Herrera wrote:
> I think vacuuming for global indexes is somewhat challenging as well :-)
> Maybe not as much as for indirect indexes, that's true.
>
> In order for it to be sustainable, I think you'll want to reuse
> partition identifiers when the partitions
On 2019-Jun-07, Peter Geoghegan wrote:
> On Thu, Jun 6, 2019 at 3:00 PM David Rowley
> wrote:
> > You may already be aware, but another use case for such variable-width
> > identifiers was with indirect indexes as discussed in [1]
>
> Right. I went with global indexes because indirect indexes ar
On Thu, Jun 6, 2019 at 3:00 PM David Rowley
wrote:
> You may already be aware, but another use case for such variable-width
> identifiers was with indirect indexes as discussed in [1]
Right. I went with global indexes because indirect indexes are
probably a lot more risky as a project. I'd be par
On Fri, 7 Jun 2019 at 08:48, Peter Geoghegan wrote:
> Andres has
> suggested that I work on variable-width table identifiers in nbtree
> for the benefit of pluggable storage engines, but I don't have much
> enthusiasm for the idea of doing that without delivering a clear
> benefit to users in the
On Thu, Jun 6, 2019 at 10:03 AM Alvaro Herrera wrote:
> If you are saying that you think that Postgres should support primary
> keys that don't necessarily overlap partition keys, then I agree with
> you. Please send a patch to implement that capability.
FWIW, I could probably be convinced to wo
On Thu, 6 Jun 2019 at 18:03, Alvaro Herrera
wrote:
> On 2019-Jun-06, Alex V. wrote:
>
> > I think that your position about primary keys in partitional tables is
> > not right.
> >
> > If we see regular table, one-field primary key is cross-table unique.
> > In partitional tables for users view we
On 2019-Jun-06, Alex V. wrote:
> I think that your position about primary keys in partitional tables is
> not right.
>
> If we see regular table, one-field primary key is cross-table unique.
> In partitional tables for users view we MUST also seen unique
> one-field primary key because this is us
>> CREATE TABLE public.test1 (
>> x1 integer NOT NULL,
>> x2 integer NOT NULL,
>> CONSTRAINT test1_pkey PRIMARY KEY (x1) INCLUDE(x2)
>> ) PARTITION BY RANGE (x2);
>> This query works in 11.1 but fails in 11.3 with messages:
>> ERROR: insufficient columns in PRIMARY KEY constraint d
User writes:
> CREATE TABLE public.test1 (
> x1 integer NOT NULL,
> x2 integer NOT NULL,
> CONSTRAINT test1_pkey PRIMARY KEY (x1) INCLUDE(x2)
> ) PARTITION BY RANGE (x2);
> This query works in 11.1 but fails in 11.3 with messages:
> ERROR: insufficient columns in PRIMARY KEY const
18 matches
Mail list logo
