I noticed that development on the concurrent index creation for partitioned
tables feature seemed to stall a few months ago. The patch looked solid,
and there didn’t seem to be any issues with it. Has there been any further
progress? This feature would be invaluable, given the prevalence of
partiti
On Fri, Jul 12, 2024 at 11:17:25PM +0100, Ilya Gladyshev wrote:
> Sure, created a separate thread [1]. Please disregard the second patch in
> this thread. Duplicating the last version of the relevant patch here to
> avoid any confusion.
>
> [1]
> https://www.postgresql.org/message-id/b72f2d89-820
On 12.07.2024 01:01, Michael Paquier wrote:
Please let's move this point to its own thread and deal with it with
an independent patch. Hiding that in a thread that's already quite
long is not a good idea. This needs proper review, and a separate
thread with a good subject to describe the probl
On Thu, Jul 11, 2024 at 09:35:24PM +0100, Ilya Gladyshev wrote:
> It is broken in master, I just didn’t want to create a separate
> thread, but it can be fixed independently. As I remember, the
> problem is that progress is tracked for each table in the hierarchy
> as if the table is processed sepa
It is broken in master, I just didn’t want to create a separate thread, but it
can be fixed independently. As I remember, the problem is that progress is
tracked for each table in the hierarchy as if the table is processed
separately, without ever setting partitions_total and partitions_done cou
On Sat, Jun 15, 2024 at 07:56:38PM +0100, Ilya Gladyshev wrote:
> In addition, I noticed that progress tracking is once again broken for
> partitioned tables, while looking at REINDEX implementation, attaching the
> second patch to fix it.
Thanks for the fixes, I started reviewing them but need so
On 15.06.2024 20:40, Justin Pryzby wrote:
On Thu, May 23, 2024 at 10:14:57PM +0100, Ilya Gladyshev wrote:
Hi,
I think it's well worth the effort to revive the patch, so I rebased it on
master, updated it and will return it back to the commitfest. Alexander,
Justin feel free to add yourselves a
On Thu, May 23, 2024 at 10:14:57PM +0100, Ilya Gladyshev wrote:
> Hi,
>
> I think it's well worth the effort to revive the patch, so I rebased it on
> master, updated it and will return it back to the commitfest. Alexander,
> Justin feel free to add yourselves as authors
Thanks -- I was intending
On 28.05.2024 07:05, Alexander Pyhalov wrote:
Ilya Gladyshev писал(а) 2024-05-28 02:52:
Also I'd like to note that in new patch version there's a strange
wording in documentation:
"This can be very convenient as not only will all existing
partitions be
indexed, but any future partitions w
Ilya Gladyshev писал(а) 2024-05-28 02:52:
Also I'd like to note that in new patch version there's a strange
wording in documentation:
"This can be very convenient as not only will all existing partitions
be
indexed, but any future partitions will be as well.
CREATE INDEX ... CONCURRENTLY c
On 24.05.2024 10:04, Alexander Pyhalov wrote:
Ilya Gladyshev писал(а) 2024-05-24 00:14:
Hi,
Hi.
I think it's well worth the effort to revive the patch, so I rebased
it on master, updated it and will return it back to the commitfest.
Alexander, Justin feel free to add yourselves as author
Ilya Gladyshev писал(а) 2024-05-24 00:14:
Hi,
Hi.
I think it's well worth the effort to revive the patch, so I rebased it
on master, updated it and will return it back to the commitfest.
Alexander, Justin feel free to add yourselves as authors
On 29.01.2024 12:43, Alexander Pyhalov wrote
Hi,
I think it's well worth the effort to revive the patch, so I rebased it
on master, updated it and will return it back to the commitfest.
Alexander, Justin feel free to add yourselves as authors
On 29.01.2024 12:43, Alexander Pyhalov wrote:
Hi.
I've rebased patch on master and it'seems t
Hi.
I've rebased patch on master and it'seems to me there's one more issue -
when we call DefineIndexConcurrentInternal() in partitioned case, it
waits for transactions, locking tableId, not tabrelid - heaprelid
LockRelId is constructed for parent index relation, not for child index
relation.
Justin Pryzby писал 2023-07-13 05:27:
On Mon, Mar 27, 2023 at 01:28:24PM +0300, Alexander Pyhalov wrote:
Justin Pryzby писал 2023-03-26 17:51:
> On Sun, Dec 04, 2022 at 01:09:35PM -0600, Justin Pryzby wrote:
> > This currently handles partitions with a loop around the whole CIC
> > implementatio
On Mon, Mar 27, 2023 at 01:28:24PM +0300, Alexander Pyhalov wrote:
> Justin Pryzby писал 2023-03-26 17:51:
> > On Sun, Dec 04, 2022 at 01:09:35PM -0600, Justin Pryzby wrote:
> > > This currently handles partitions with a loop around the whole CIC
> > > implementation, which means that things like W
Justin Pryzby писал 2023-03-26 17:51:
On Sun, Dec 04, 2022 at 01:09:35PM -0600, Justin Pryzby wrote:
This currently handles partitions with a loop around the whole CIC
implementation, which means that things like WaitForLockers() happen
once for each index, the same as REINDEX CONCURRENTLY on a
On Sun, Dec 04, 2022 at 01:09:35PM -0600, Justin Pryzby wrote:
> This currently handles partitions with a loop around the whole CIC
> implementation, which means that things like WaitForLockers() happen
> once for each index, the same as REINDEX CONCURRENTLY on a partitioned
> table. Contrast that
On Sun, 2022-12-04 at 13:09 -0600, Justin Pryzby wrote:
>
> This beavior is fixed. I re-factored and re-implented to use
> DefineIndex() for building indexes concurrently rather than
> reindexing.
> That makes the patch smaller, actually, and has the added benefit of
> splitting off the "Concurre
On Sat, Dec 03, 2022 at 07:13:30PM +0400, Ilya Gladyshev wrote:
> Hi,
>
> Thank you Justin and Alexander for working on this, I have reviewed and
> tested the latest patch, it works well, the problems mentioned
> previously are all fixed. I like the idea of sharing code of reindex
> and index, but
Hi,
Thank you Justin and Alexander for working on this, I have reviewed and
tested the latest patch, it works well, the problems mentioned
previously are all fixed. I like the idea of sharing code of reindex
and index, but I have noticed some peculiarities as a user.
The reporting is somewhat co
Justin Pryzby писал 2022-11-21 06:00:
I finally found time to digest and integrate your changes into my local
branch. This fixes the three issues you reported: FORCE_RELEASE, issue
with INVALID partitions issue (for which I adapted your patch into an
earlier patch in my series), and progress rep
I finally found time to digest and integrate your changes into my local
branch. This fixes the three issues you reported: FORCE_RELEASE, issue
with INVALID partitions issue (for which I adapted your patch into an
earlier patch in my series), and progress reporting. And rebased.
--
Justin
>From
Justin Pryzby писал 2022-06-28 21:33:
Hi,
On Thu, Feb 10, 2022 at 06:07:08PM +0300, Alexander Pyhalov wrote:
I've rebased patches and tried to fix issues I've seen. I've fixed
reference
after table_close() in the first patch (can be seen while building
with
CPPFLAGS='-DRELCACHE_FORCE_RELEASE'
Justin Pryzby писал 2022-06-28 21:33:
Hi,
On Thu, Feb 10, 2022 at 06:07:08PM +0300, Alexander Pyhalov wrote:
I've rebased patches and tried to fix issues I've seen. I've fixed
reference
after table_close() in the first patch (can be seen while building
with
CPPFLAGS='-DRELCACHE_FORCE_RELEASE'
Hi,
On Thu, Feb 10, 2022 at 06:07:08PM +0300, Alexander Pyhalov wrote:
> I've rebased patches and tried to fix issues I've seen. I've fixed reference
> after table_close() in the first patch (can be seen while building with
> CPPFLAGS='-DRELCACHE_FORCE_RELEASE').
Thanks for finding that.
The pat
On Fri, Mar 25, 2022 at 01:05:49AM -0400, Greg Stark wrote:
> This patch is marked "waiting on author" in the CF. However the most
> recent emails have patches and it's not clear to me what's left from
> previous reviews that might not be addressed yet. Should this patch be
> marked "Needs Review"?
This patch is marked "waiting on author" in the CF. However the most
recent emails have patches and it's not clear to me what's left from
previous reviews that might not be addressed yet. Should this patch be
marked "Needs Review"?
Anastasia and Alexander are marked as reviewers. Are you still abl
Hi.
I've added 0005-Mark-intermediate-partitioned-indexes-as-valid.patch
which fixed the following issues - when partitioned index is created,
indexes on intermediate partitioned tables were preserved in invalid
state. Also added some more tests.
--
Best regards,
Alexander Pyhalov,
Postgres P
Justin Pryzby писал 2021-02-26 21:20:
On Mon, Feb 15, 2021 at 10:07:05PM +0300, Anastasia Lubennikova wrote:
5) Speaking of documentation, I think we need to add a paragraph about
CIC
on partitioned indexes which will explain that invalid indexes may
appear
and what user should do to fix them.
Alexander Pyhalov писал 2022-02-09 15:18:
Hi.
I've looked at patches, introducing CREATE INDEX CONCURRENTLY for
partitioned tables -
https://www.postgresql.org/message-id/flat/20210226182019.GU20769%40telsasoft.com#da169a0a518bf8121604437d9ab053b3
.
The thread didn't have any activity for a year
On Mon, Feb 15, 2021 at 10:07:05PM +0300, Anastasia Lubennikova wrote:
> 5) Speaking of documentation, I think we need to add a paragraph about CIC
> on partitioned indexes which will explain that invalid indexes may appear
> and what user should do to fix them.
I'm not sure about that - it's alre
Hi,
For v13-0006-More-refactoring.patch :
+ /* It's not a shared catalog, so refuse to move it to shared tablespace
*/
+ if (params->tablespaceOid == GLOBALTABLESPACE_OID && false)
+ ereport(ERROR,
Do you intend to remove the ineffective check ?
+ else
+ heapRelation =
On Mon, Feb 15, 2021 at 10:06:47PM +0300, Anastasia Lubennikova wrote:
> On 28.01.2021 17:30, Justin Pryzby wrote:
> > On Thu, Jan 28, 2021 at 09:51:51PM +0900, Masahiko Sawada wrote:
> > > On Mon, Nov 30, 2020 at 5:22 AM Justin Pryzby
> > > wrote:
> > > > On Sat, Oct 31, 2020 at 01:31:17AM -0500
On 28.01.2021 17:30, Justin Pryzby wrote:
On Thu, Jan 28, 2021 at 09:51:51PM +0900, Masahiko Sawada wrote:
On Mon, Nov 30, 2020 at 5:22 AM Justin Pryzby wrote:
On Sat, Oct 31, 2020 at 01:31:17AM -0500, Justin Pryzby wrote:
Forking this thread, since the existing CFs have been closed.
https://
On 28.01.2021 17:30, Justin Pryzby wrote:
On Thu, Jan 28, 2021 at 09:51:51PM +0900, Masahiko Sawada wrote:
On Mon, Nov 30, 2020 at 5:22 AM Justin Pryzby wrote:
On Sat, Oct 31, 2020 at 01:31:17AM -0500, Justin Pryzby wrote:
Forking this thread, since the existing CFs have been closed.
https://
On Thu, Jan 28, 2021 at 09:51:51PM +0900, Masahiko Sawada wrote:
> On Mon, Nov 30, 2020 at 5:22 AM Justin Pryzby wrote:
> > On Sat, Oct 31, 2020 at 01:31:17AM -0500, Justin Pryzby wrote:
> > > Forking this thread, since the existing CFs have been closed.
> > > https://www.postgresql.org/message-id
On Mon, Nov 30, 2020 at 5:22 AM Justin Pryzby wrote:
>
> On Sat, Oct 31, 2020 at 01:31:17AM -0500, Justin Pryzby wrote:
> > Forking this thread, since the existing CFs have been closed.
> > https://www.postgresql.org/message-id/flat/20200914143102.GX18552%40telsasoft.com#58b1056488451f8594b0f0ba40
On Sat, Oct 31, 2020 at 01:31:17AM -0500, Justin Pryzby wrote:
> Forking this thread, since the existing CFs have been closed.
> https://www.postgresql.org/message-id/flat/20200914143102.GX18552%40telsasoft.com#58b1056488451f8594b0f0ba40996afd
>
> The strategy is to create catalog entries for all
Forking this thread, since the existing CFs have been closed.
https://www.postgresql.org/message-id/flat/20200914143102.GX18552%40telsasoft.com#58b1056488451f8594b0f0ba40996afd
The strategy is to create catalog entries for all tables with indisvalid=false,
and then process them like REINDEX CONCUR
40 matches
Mail list logo
