From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Smith <smithpb2250(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Load TIME fields - proposed performance improvement |
Date: | 2020-09-22 02:44:27 |
Message-ID: | 1136659.1600742667@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2020-09-22 02:47:04 | Re: shared-memory based stats collector |
Previous Message | Tom Lane | 2020-09-22 02:12:45 | Re: Load TIME fields - proposed performance improvement |