Lists: | pgsql-hackers |
---|
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | WIP patch for system-catalog vacuuming via a relation map |
Date: | 2010-02-05 21:56:22 |
Message-ID: | 6690.1265406982@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Attached is the current state of my work on letting system catalogs
be processed by new-style VACUUM FULL (a/k/a CLUSTER). I haven't done
the WAL support nor worried about interlocking concurrent updates of
relation map files, but it passes the regression tests and can do
VACUUM FULL of every system catalog. So I think this is proof that
the approach is workable and there are no further gotchas to stumble
over in dark recesses of the system. The patch adds about 1250 lines
of code, mostly in a new file relmapper.c, and will be bigger once
WAL support is added. However, I anticipate that we will be able to
rip out probably three times that much code by eliminating VACUUM FULL
INPLACE (commands/vacuum.c is alone almost 4000 lines, though of course
it won't all go away). So it will be a substantial net reduction in
code size, plus we will get the previously discussed benefits such as
removing reindex-in-place for shared indexes.
Barring objections I'm going to press ahead with completing and
committing this; then in a separate patch remove VACUUM FULL INPLACE.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
relation-mapper-1.patch.gz | application/octet-stream | 30.3 KB |
From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: WIP patch for system-catalog vacuuming via a relation map |
Date: | 2010-02-05 22:00:23 |
Message-ID: | 20100205220023.GD3736@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Barring objections I'm going to press ahead with completing and
> committing this; then in a separate patch remove VACUUM FULL INPLACE.
With the second patch, we will continue to support reading
XVAC_MOVED_OUT and IN hint bits, but never set them, correct?
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: WIP patch for system-catalog vacuuming via a relation map |
Date: | 2010-02-05 22:07:47 |
Message-ID: | 7640.1265407667@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Tom Lane wrote:
>> Barring objections I'm going to press ahead with completing and
>> committing this; then in a separate patch remove VACUUM FULL INPLACE.
> With the second patch, we will continue to support reading
> XVAC_MOVED_OUT and IN hint bits, but never set them, correct?
Right, the tqual support has to stay for as long as we support binary
upgrade from previous releases. (Unless we want to work out some way
of ensuring no MOVED bits remain set in a database.) There is one
heck of a lot of other infrastructure and complexity that can go away,
though.
regards, tom lane
From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WIP patch for system-catalog vacuuming via a relation map |
Date: | 2010-02-05 22:22:16 |
Message-ID: | 4B6C9A18.90202@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
> Barring objections I'm going to press ahead with completing and
> committing this; then in a separate patch remove VACUUM FULL INPLACE.
Was it our determination that we could remove VFI if we eliminated the
system catalogs? I'm fine with it, I just thought some people had a
marginal use case for VFI.
--Josh Berkus
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WIP patch for system-catalog vacuuming via a relation map |
Date: | 2010-02-05 22:34:23 |
Message-ID: | 8052.1265409263@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> Barring objections I'm going to press ahead with completing and
>> committing this; then in a separate patch remove VACUUM FULL INPLACE.
> Was it our determination that we could remove VFI if we eliminated the
> system catalogs? I'm fine with it, I just thought some people had a
> marginal use case for VFI.
I thought the consensus was to remove it if possible. There may still
be some "marginal" use cases, but they don't justify the work that'd
be needed to make it play safely with HS; let alone fixing the other
longstanding gotchas with it, like the double-commit risk.
regards, tom lane
From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WIP patch for system-catalog vacuuming via a relation map |
Date: | 2010-02-05 22:52:25 |
Message-ID: | 201002052252.o15MqPB06213@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
> >> Barring objections I'm going to press ahead with completing and
> >> committing this; then in a separate patch remove VACUUM FULL INPLACE.
>
> > Was it our determination that we could remove VFI if we eliminated the
> > system catalogs? I'm fine with it, I just thought some people had a
> > marginal use case for VFI.
>
> I thought the consensus was to remove it if possible. There may still
> be some "marginal" use cases, but they don't justify the work that'd
> be needed to make it play safely with HS; let alone fixing the other
> longstanding gotchas with it, like the double-commit risk.
Oh, yea, I remember, HS killed it because of the work required to make
FULL work for 9.0. Thanks.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WIP patch for system-catalog vacuuming via a relation map |
Date: | 2010-02-06 00:24:57 |
Message-ID: | 4B6CB6D9.9040901@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
>>> Barring objections I'm going to press ahead with completing and
>>> committing this; then in a separate patch remove VACUUM FULL INPLACE.
>
>> Was it our determination that we could remove VFI if we eliminated the
>> system catalogs? I'm fine with it, I just thought some people had a
>> marginal use case for VFI.
>
> I thought the consensus was to remove it if possible. There may still
> be some "marginal" use cases, but they don't justify the work that'd
> be needed to make it play safely with HS; let alone fixing the other
> longstanding gotchas with it, like the double-commit risk.
I think part of the plan was to also provide an online reorg tool that
works by doing dummy UPDATEs, which means that you can get serialization
errors in serializable mode, but doesn't need to lock the table.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WIP patch for system-catalog vacuuming via a relation map |
Date: | 2010-02-06 00:55:06 |
Message-ID: | 21062.1265417706@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> Tom Lane wrote:
>> I thought the consensus was to remove it if possible. There may still
>> be some "marginal" use cases, but they don't justify the work that'd
>> be needed to make it play safely with HS; let alone fixing the other
>> longstanding gotchas with it, like the double-commit risk.
> I think part of the plan was to also provide an online reorg tool that
> works by doing dummy UPDATEs, which means that you can get serialization
> errors in serializable mode, but doesn't need to lock the table.
Yeah. There's a good deal of interest in incremental/partial vacuuming.
But that wouldn't make use of the existing VFI infrastructure either.
regards, tom lane