Re: Patches for TODO item: Avoid truncating empty OCDR temp tables on COMMIT

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>, PGSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patches for TODO item: Avoid truncating empty OCDR temp tables on COMMIT
Date: 2013-01-29 02:41:16
Message-ID: CA+TgmoajveF03pgPwPO2=OQswcGO3M8-BwymwR9kA==r4bpaMA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 28, 2013 at 8:39 AM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> On 15.01.2013 21:03, Tom Lane wrote:
>> Robert Haas<robertmhaas(at)gmail(dot)com> writes:
>>>
>>> On the third hand, the fact that a table is OCDR is recorded in
>>> backend-local storage somewhere, and that storage (unlike the
>>> relcache) had better be reliable. So maybe there's some way to
>>> finesse it that way.
>>
>> Hm, keep a flag in that storage you mean? Yeah, that could possibly
>> work.
>
> Sounds reasonable.
>
> Until someone gets around to write a patch along those lines, I'm inclined
> to apply this one liner:
>
> *** a/src/backend/commands/tablecmds.c
> --- b/src/backend/commands/tablecmds.c
> ***************
> *** 10124,10130 **** PreCommit_on_commit_actions(void)
> /* Do nothing (there shouldn't be such
> entries, actually) */
> break;
> case ONCOMMIT_DELETE_ROWS:
> ! oids_to_truncate =
> lappend_oid(oids_to_truncate, oc->relid);
> break;
> case ONCOMMIT_DROP:
> {
> --- 10124,10136 ----
> /* Do nothing (there shouldn't be such
> entries, actually) */
> break;
> case ONCOMMIT_DELETE_ROWS:
> ! /*
> ! * If this transaction hasn't accessed any
> temporary relations,
> ! * we can skip truncating ON COMMIT DELETE
> ROWS tables, as
> ! * they must still be empty.
> ! */
> ! if (MyXactAccessedTempRel)
> ! oids_to_truncate =
> lappend_oid(oids_to_truncate, oc->relid);
> break;
> case ONCOMMIT_DROP:
> {
>
> We already have that MyXactAccessedTempRel global flag. Just checking that
> should cover many common cases.

+1 for that. I'm actually unconvinced that we need to do any better
than that in general. But certainly that seems like a good first
step.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2013-01-29 02:47:27 Re: pg_ctl idempotent option
Previous Message Robert Haas 2013-01-29 02:39:27 Re: unlogged tables vs. GIST