From: | Marc Millas <marc(dot)millas(at)mokadb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: how to "explain" some ddl |
Date: | 2020-07-14 19:31:58 |
Message-ID: | CADX_1aYuUR0822A5h7PJz1p51kQDLD1nRXEQ8JhJz8gpQGah1g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi Tom,
a few tests later.
Looks like when you add a partition as default, all tupples of it are read,
even if there is an index on the column that is the partition key.
this do explain our attach time. We are going to clean the default
partition...
regards,
Marc MILLAS
Senior Architect
+33607850334
www.mokadb.com
On Tue, Jul 14, 2020 at 7:05 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Marc Millas <marc(dot)millas(at)mokadb(dot)com> writes:
> > We would like to understand where an alter table attach partition spend
> its
> > time.
> > to my understanding, explain doesnt do this.
>
> Nope :-(. As our DDL commands have gotten more complicated, there's
> been some discussion of adding that, but nothing's really been done
> yet.
>
> There is some progress-monitoring support for some DDL commands now,
> but that's not quite the same thing.
>
> > for a BI job we have a partitionned table with 1800+ partitions.
>
> TBH I'd recommend scaling that down by at least a factor of ten.
> We are not at a point where you can expect that all operations will
> be cheap even with thousands of partitions. We may never be at that
> point, although people continue to chip away at the bottlenecks.
>
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2020-07-14 20:04:01 | Re: Problem with FDW wrapper errors |
Previous Message | Radoslav Nedyalkov | 2020-07-14 19:31:39 | Re: single table - fighting a seq scan |