aboutsummaryrefslogtreecommitdiff
path: root/src/backend/parser/parse_expr.c
diff options
context:
space:
mode:
authorBruce Momjian <bruce@momjian.us>2005-06-04 20:14:12 +0000
committerBruce Momjian <bruce@momjian.us>2005-06-04 20:14:12 +0000
commit3cf1fd3263ee4fd585df80fb235c855b8a97426d (patch)
tree8a3f98050d3a26528a0f563648394e814ce88b96 /src/backend/parser/parse_expr.c
parente18e8f873594fd4ff2f12e734a624102d3ef1e39 (diff)
downloadpostgresql-3cf1fd3263ee4fd585df80fb235c855b8a97426d.tar.gz
postgresql-3cf1fd3263ee4fd585df80fb235c855b8a97426d.zip
Tom Lane <tgl@sss.pgh.pa.us> writes:
> a_ogawa <a_ogawa@hi-ho.ne.jp> writes: > > It is a reasonable idea. However, the majority part of MemSet was not > > able to be avoided by this idea. Because the per-tuple contexts are used > > at the early stage of executor. > > Drat. Well, what about changing that? We could introduce additional > contexts or change the startup behavior so that the ones that are > frequently reset don't have any data in them unless you are working > with pass-by-ref values inside the inner loop. That might be possible. However, I think that we should change only aset.c about this article. I thought further: We can check whether context was used from the last reset even when blocks list is not empty. Please see attached patch. The effect of the patch that I measured is as follows: o Execution time that executed the SQL ten times. (1)Linux(CPU: Pentium III, Compiler option: -O2) - original: 24.960s - patched : 23.114s (2)Linux(CPU: Pentium 4, Compiler option: -O2) - original: 8.730s - patched : 7.962s (3)Solaris(CPU: Ultra SPARC III, Compiler option: -O2) - original: 37.0s - patched : 33.7s Atsushi Ogawa (a_ogawa)
Diffstat (limited to 'src/backend/parser/parse_expr.c')
0 files changed, 0 insertions, 0 deletions