Re: Cache last known per-tuple offsets to speed long tuple - Mailing list pgsql-patches

From Bruce Momjian
Subject Re: Cache last known per-tuple offsets to speed long tuple
Date
Msg-id 200411280333.iAS3XDL10603@candle.pha.pa.us
Whole thread Raw
In response to Re: Cache last known per-tuple offsets to speed long tuple  (a_ogawa <a_ogawa@hi-ho.ne.jp>)
List 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@hi-ho.ne.jp

[ Attachment, skipping... ]

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

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

pgsql-patches by date:

Previous
From: "Dave Page"
Date:
Subject: Re: [pgsql-hackers-win32] [BUGS] pg_autovacuum in 8beta-dev3 small bug
Next
From: Simon Riggs
Date:
Subject: Re: [DOCS] SQL conformance related patch