HOT patches

Hi All,

Please see the set of HOT patches, broken down as suggested by
the community members for easy review. There are 5 patches, they
should apply cleanly on current CVS HEAD, but have dependencies.
So one must apply patch1 before applying patch2 and so on. At
each stage, code compiles and passes regression tests, though
things like CREATE INDEX and VACUUM may be broken until the
corresponding patches are applied. Though I've tried to decouple
the patch logically, some part of the patch may not make sense
until the later patch is reviewed. Please let me know if such things
exist.

HOT-split1.patch has the basic HOT code. It implements HOT update
if there is enough free space in the same block and none of the index
keys are changed. This should serve as a good starting point to
get the basic HOT principle without getting into any complex
optimizations.

HOT-split2.patch adds a lot of logic for further optimization such as
chain pruning, reusing LP_deleted tuples, line-pointer redirection
and row-level de-fragmentation. This patch still looks heavy, but its
difficult to split it up further. Even so, if necessary, I can try to that.

HOT-split3.patch adds some misc stuff regarding pg_stats

HOT-split4.patch fixes the VACUUM [FULL] related issues

HOT-split5.patch fixes the CREATE INDEX [CONCURRENTLY] related issue.

Please let me know if further break down is required. I would be more
than happy to provide any other support to ease the review process.

Thanks,
Pavan

--

EnterpriseDB http://www.enterprisedb.com

Hi,

Pavan Deolasee írta:
>
> Hi All,
>
> Please see the set of HOT patches, broken down as suggested by
> the community members for easy review. There are 5 patches, they
> should apply cleanly on current CVS HEAD, but have dependencies.
> So one must apply patch1 before applying patch2 and so on. At
> each stage, code compiles and passes regression tests, though
> things like CREATE INDEX and VACUUM may be broken until the
> corresponding patches are applied. [skip]

I tried your patchset on current CVS (some minutes old) and
got this single regression below.

*** ./expected/create_index.out Mon Apr 9 11:35:52 2007
--- ./results/create_index.out Mon May 7 17:08:45 2007
***************
*** 415,420 ****
--- 415,421 ----
f2 | text |
Indexes:
"concur_index2" UNIQUE, btree (f1)
+ "concur_index3" UNIQUE, btree (f2) INVALID
"concur_index1" btree (f2, f1)
"concur_index4" btree (f2) WHERE f1 = 'a'::text
"concur_index5" btree (f2) WHERE f1 = 'x'::text

======================================================================

I had the same with your v7.0 as well.
It seems the failed indexes aren't cleaned up properly,
this is in both expected/create_index.out and results/create_index.out:

CREATE UNIQUE INDEX CONCURRENTLY concur_index3 ON concur_heap(f2);
ERROR: could not create unique index
DETAIL: Table contains duplicated values.

Do you build and run the regression tests on single-core single-CPU
machine or on SMP? I got the above on an Athlon64 X2.

Best regards,
Zoltán Böszörményi

--
----------------------------------
Zoltán Böszörményi
Cybertec Geschwinde & Schönig GmbH
http://www.postgresql.at/

On 5/7/07, Zoltan Boszormenyi <zb(at)cybertec(dot)at> wrote:
>
>
>
> I tried your patchset on current CVS (some minutes old) and
> got this single regression below.
>
>
Thanks for testing the patch. This failure is expected and I had mentioned
this when I posted v7. With HOT, CIC is now a three step process
and a failure after the first step will leave an invalid index behind. In
this particular case, CIC fails because of duplicate keys.

I did not deliberately fix the regression output to highlight this change.

Thanks,
Pavan

--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com