Subject: Re: gettimeofday is at the end of its usefulness?
To: Tom Lane <tgl@sss.pgh.pa.us>, Thom Brown <thom@linux.com>
References: <31856.1400021891@sss.pgh.pa.us>
 <20140515185614.GG25053@momjian.us>
 <CAA-aLv7m=RU0vKm1myt_uRLYmTviqFcfWZCMPwbXdbKoX4YzYg@mail.gmail.com>
 <20237.1465397783@sss.pgh.pa.us>
CC: Bruce Momjian <bruce@momjian.us>, PostgreSQL-development
	<pgsql-hackers@postgresql.org>
From: Jim Nasby <Jim.Nasby@BlueTreble.com>
Message-ID: <41c674c8-e6e4-a706-37b4-1ed097663a9f@BlueTreble.com>
Date: Tue, 14 Jun 2016 15:27:07 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0)
 Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <20237.1465397783@sss.pgh.pa.us>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (protection.outlook.com: bluetreble.com does not designate
 permitted sender hosts)
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jun 2016 20:30:25.4871 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR11MB0684
X-Pg-Spam-Score: -1.9 (-)
List-Archive: <http://archives.postgresql.org/pgsql-hackers>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-hackers.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@postgresql.org>
List-Post: <mailto:pgsql-hackers@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-hackers>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 6/8/16 9:56 AM, Tom Lane wrote:
> Thom Brown <thom@linux.com> writes:
>> On 15 May 2014 at 19:56, Bruce Momjian <bruce@momjian.us> wrote:
>>> On Tue, May 13, 2014 at 06:58:11PM -0400, Tom Lane wrote:
>>>> A recent question from Tim Kane prompted me to measure the overhead
>>>> costs of EXPLAIN ANALYZE, which I'd not checked in awhile.  Things
>>>> are far worse than I thought.  On my current server (by no means
>>>> lavish hardware: Xeon E5-2609 @2.40GHz) a simple seqscan can run
>>>> at something like 110 nsec per row:
>
>> Did this idea die, or is it still worth considering?
>
> We still have a problem, for sure.  I'm not sure that there was any
> consensus on what to do about it.  Using clock_gettime(CLOCK_REALTIME)
> if available would be a straightforward change that should ameliorate
> gettimeofday()'s 1-usec-precision-limit problem; but it doesn't do
> anything to fix the excessive-overhead problem.  The ideas about the
> latter were all over the map, and none of them looked easy.
>
> If you're feeling motivated to work on this area, feel free.

Semi-related: someone (Robert I think) recently mentioned investigating 
"vectorized" executor nodes, where multiple tuples would be processed in 
one shot. If we had that presumably the explain penalty would be a moot 
point.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)   mobile: 512-569-9461


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