Re: Load TIME fields - proposed performance improvement
От | Tom Lane |
---|---|
Тема | Re: Load TIME fields - proposed performance improvement |
Дата | |
Msg-id | 1136659.1600742667@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
|
Список | pgsql-hackers |
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 по дате отправления: