From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Petr Fedorov <petr(dot)fedorov(at)phystech(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch |
Date: | 2020-08-12 07:04:07 |
Message-ID: | be30c07c-3f7b-7c86-f1c5-d0858046b26f@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Here is a new patch series version.
I have created a new internal function for converting integers to
numeric, to make the implementation a bit more elegant and compact.
I have also created a new date_part(..., date) in C, and added more test
coverage for that.
Other than some of the semantic issues mentioned in the previous
message, this version looks pretty good to me in principle.
I have done some performance tests to assess the impact of changing from
float to numeric. I did tests like this:
create table t1 (a int, b timestamp with time zone);
insert into t1 select generate_series(1, 10000000), current_timestamp +
random() * interval '1000 days';
select extract(dow from b) from t1 \g /dev/null
select extract(epoch from b) from t1 \g /dev/null
There appears to be about a 20% increase in run time for these tests.
These are obviously extreme tests, so I think that would be okay. More
tests and testing ideas are welcome.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment | Content-Type | Size |
---|---|---|
v2-0001-Add-more-tests-for-extract-of-date-type.patch | text/plain | 11.5 KB |
v2-0002-Expose-internal-function-for-converting-int64-to-.patch | text/plain | 12.7 KB |
v2-0003-Change-return-type-of-EXTRACT-to-numeric.patch | text/plain | 84.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2020-08-12 07:45:03 | BUG #16578: When making an insert, the database goes to recover mode |
Previous Message | Amit Langote | 2020-08-12 05:19:12 | Re: posgres 12 bug (partitioned table) |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2020-08-12 07:12:07 | remove some ancient port hacks |
Previous Message | Masahiko Sawada | 2020-08-12 06:32:39 | Re: SyncRepLock acquired exclusively in default configuration |