From: Tom Lane <tgl@sss.pgh.pa.us>
To: Fabien COELHO <coelho@cri.ensmp.fr>
cc: PostgreSQL Developers <pgsql-hackers@postgresql.org>
Subject: Re: Fixing pgbench's logging of transaction timestamps
In-reply-to: <18059.1483302133@sss.pgh.pa.us>
References: <8837.1483216839@sss.pgh.pa.us>
 <alpine.DEB.2.20.1701011128380.15074@lancre> <18059.1483302133@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Sun, 01 Jan 2017 15:22:13 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <20258.1483378111.1@sss.pgh.pa.us>
Date: Mon, 02 Jan 2017 12:28:31 -0500
Message-ID: <20259.1483378111@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

I wrote:
> BTW, why is it that the --aggregate-interval option is unsupported on
> Windows?  Is that an artifact of the same disease of assuming too much
> about how instr_time is represented?  I don't see any very good reason
> for it other than the weird decision to store the result of
> INSTR_TIME_GET_DOUBLE in a "long", which seems rather broken in any case.

After looking closer, I see the real issue is that it prints the integer
part of INSTR_TIME_GET_DOUBLE and documents that as being a Unix
timestamp.  So that's not going to do either.  I solved it the same way
as in the other code path, ie just eat the cost of doing our own time
inquiry.

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers