Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch

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

In response to

Responses

Browse pgsql-bugs by date

  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)

Browse pgsql-hackers by date

  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