Re: Load TIME fields - proposed performance improvement
От
Tom Lane
Тема
Re: Load TIME fields - proposed performance improvement
Дата
Msg-id
1136659.1600742667@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
Load TIME fields - proposed performance improvement Peter Smith <smithpb2250@gmail.com>
Re: Load TIME fields - proposed performance improvement Tom Lane <tgl@sss.pgh.pa.us>
Re: Load TIME fields - proposed performance improvement Tom Lane <tgl@sss.pgh.pa.us>
Re: Load TIME fields - proposed performance improvement Peter Smith <smithpb2250@gmail.com>
Re: Load TIME fields - proposed performance improvement Peter Smith <smithpb2250@gmail.com>
Re: Load TIME fields - proposed performance improvement Tom Lane <tgl@sss.pgh.pa.us>
Re: Load TIME fields - proposed performance improvement Peter Smith <smithpb2250@gmail.com>
Re: Load TIME fields - proposed performance improvement Tom Lane <tgl@sss.pgh.pa.us>
Re: Load TIME fields - proposed performance improvement Peter Smith <smithpb2250@gmail.com>
I wrote: > Interesting idea, but this implementation is leaving a *lot* > on the table. If we want to cache the result of > timestamp2tm applied to GetCurrentTransactionStartTimestamp(), > there are half a dozen different call sites that could make > use of such a cache, eg, GetSQLCurrentDate and GetSQLCurrentTime. As an example, I did some quick-and-dirty "perf" measurement of this case: create table t1 (id int, d date default current_date); insert into t1 select generate_series(1,100000000); and found that about 10% of the runtime is spent inside timestamp2tm(). Essentially all of that cost could be removed by a suitable caching patch. Admittedly, this is a pretty well cherry-picked example, and more realistic test scenarios might see just a percent or two win. Still, for the size of the patch I'm envisioning, it'd be well worth the trouble. regards, tom lane
В списке pgsql-hackers по дате отправления