From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Jinyu <call_jinyu(at)126(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Improve the concurency of vacuum full table and select statement on the same relation |
Date: | 2015-10-16 00:28:09 |
Message-ID: | 56204499.8050501@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/13/15 10:18 AM, Jinyu wrote:
> At 2015-10-12 23:46:12, "Jim Nasby" <Jim(dot)Nasby(at)BlueTreble(dot)com> wrote:
>>On 10/11/15 6:55 AM, Jinyu wrote:
>>> Are there other solutions to improve the concurency of vacuum
>>> full/cluster and select statement on the same relation?
>>
>>ISTM that if we were going to put effort into this it makes more sense
>>to pull pg_repack into core. BTW, it's approach to this is to summarily
>>kill anything that attempts DDL on a table being repacked.
Please don't top-post, it leads to confusion.
> >>it's approach to this is to summarily kill anything that attempts DDL
> on a table being repacked.
> Why? I am confused with it. Could you please explain this?
It's just how the authors of pg_repack decided to handle it. It seems
pretty reasonable, since you probably don't want an errant DDL statement
to cause the rollback of hours or days of pg_repack work.
Ultimately, I don't think you'll find many people interested in working
on this, because the whole goal is to never need VACUUM FULL or
pg_repack. If you're clustering just for the sake of clustering, that
has it's own set of difficulties that should be addressed.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2015-10-16 00:47:31 | Re: [PATCH] SQL function to report log message |
Previous Message | Noah Misch | 2015-10-16 00:23:49 | Re: Parallel Seq Scan |