On 1 August 2011 20:53, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
>> OK, so I should split this into 2 patches?
>> Even without the compression, it's probably worth the 16 -> 10 byte
>> reduction that would result from removing the 2nd CTID in the UPDATE
>> case, and that part would be a pretty small patch.
>
> Yeah, my point exactly. The rest of it might or might not be worth the
> extra complication.
>
OK, here's a patch for the first bit - just removing the second CTID
in the UPDATE case, and including a sanity check of the new tuple's
xmin and cmin.
It passes all the regression tests. I also tested it by doing a 10M
row UPDATE x=x+1 on a deferrable PK, and it gave about the expected
reduction in memory usage, with no difference in run time.
I'll test out the additional compression separately.
Regards,
Dean
In response to
pgsql-hackers by date
| Next: | From: Florian Pflug | Date: 2011-08-02 08:33:39 |
| Subject: Re: WIP fix proposal for bug #6123 |
| Previous: | From: Robert Haas | Date: 2011-08-02 03:10:24 |
| Subject: Re: pgbench internal contention |