Re: Cache last known per-tuple offsets to speed long tuple

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: "a_ogawa" <a_ogawa(at)hi-ho(dot)ne(dot)jp>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-patches(at)postgresql(dot)org
Subject: Re: Cache last known per-tuple offsets to speed long tuple
Date: 2004-11-28 03:33:12
Message-ID: 200411280333.iAS3XDL10603@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches


This has been saved for the 8.1 release:

http:/momjian.postgresql.org/cgi-bin/pgpatches2

---------------------------------------------------------------------------

a_ogawa wrote:
>
> I remaked patch for "Cache last known per-tuple offsets to speed
> long tuple access" that is in TODO list.
>
> The point of this patch is as follows:
> (1)Add fields to TupleTableSlot and TupleTableData.
> This fields are for holding the tuple disassembly information.
>
> (2)Add the codes which initializes/cleans new fields.
> These codes are added to execTuples.c.
>
> (3)Add two functions to execQual.c.
> This function name is slot_deformtuple and this is
> just like heap_deformtuple. This function can be resumed
> from the previous execution using the information
> encapsulated in the TupleTableSlot.
>
> Another function is just like heap_getattr and fast_getattr.
> This function name is slot_getattr. This is just like
> heap_getattr and fast_getattr macro, except it is given a
> TupleTableSlot, and this function uses slot_deformtuple
> insetead of nocachegetattr.
>
> (4)ExecEvalVar uses new function slot_getattr instead of
> heap_getattr.
>
> I executed the test below.
> -------------------
> Table has 16,384tuples, 200columns. All data type is text.
> Table name is aaa. Column name is t001...t200.
> Executed SQL is,
> select t100, t110, t120, t130, t140, t150,
> t160, t170, t180, t190, t200
> from aaa;
>
> The profile result of original code is as follows.
> -------------------
> Each sample counts as 0.01 seconds.
> % cumulative self self total
> time seconds seconds calls s/call s/call name
> 74.19 1.38 1.38 163846 0.00 0.00 nocachegetattr
> 4.30 1.46 0.08 163840 0.00 0.00 FunctionCall3
> 1.61 1.49 0.03 397750 0.00 0.00 AllocSetFreeIndex
> 1.61 1.52 0.03 16384 0.00 0.00 ExecTargetList
> 1.08 1.54 0.02 344152 0.00 0.00 appendBinaryStringInfo
>
> The profile result after the patch applying is as follows.
> -------------------
> Each sample counts as 0.01 seconds.
> % cumulative self self total
> time seconds seconds calls ms/call ms/call name
> 30.38 0.24 0.24 163840 0.00 0.00 slot_deformtuple
> 10.13 0.32 0.08 163840 0.00 0.00 FunctionCall3
> 5.06 0.36 0.04 163840 0.00 0.00 slot_getattr
> 5.06 0.40 0.04 16384 0.00 0.00 heap_deformtuple
> 3.80 0.43 0.03 49159 0.00 0.00 ExecClearTuple
>
> regards,
>
> --- Atsushi Ogawa
> a_ogawa(at)hi-ho(dot)ne(dot)jp

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Simon Riggs 2004-11-28 21:35:25 Re: [PATCHES] SQL conformance related patch
Previous Message Bruce Momjian 2004-11-28 03:32:53 Re: Problems using pgxs on Win32