Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group