Re: UUID v7

ap backward */ tms = previous_timestamp; Not sure how to fix this, but clearly something is amiss here. Thanks, Lukas -- Lukas Fittl

Re: Add estimated hit ratio to Memoize in EXPLAIN to explain cost adjustment

On Thu, Jul 6, 2023 at 12:56 AM Daniel Gustafsson wrote: > Lukas: do you have an updated patch for this commitfest to address David's > comments? > I have a draft - I should be able to post an updated patch in the next days. Thanks for checking! Thanks, Lukas -- Lukas Fittl

Add estimated hit ratio to Memoize in EXPLAIN to explain cost adjustment

hit ratio as a discussion starter. I'll park this in the July commitfest for now. Thanks, Lukas -- Lukas Fittl v1-0001-Add-Estimated-Cache-Hit-Ratio-for-Memoize-plan-no.patch Description: Binary data

Re: Sampling-based timing for EXPLAIN ANALYZE

ncy than its caller. Thanks, Lukas [1] https://postgr.es/m/20230116213913.4oseovlzvc2674z7%40awork3.anarazel.de -- Lukas Fittl v2-0001-Add-TIMING-SAMPLING-option-for-EXPLAIN-ANALYZE.patch Description: Binary data

Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?

gresql.org/message-id/CAP53PkxXMk0j-%2B0%3DYwRti2pFR5UB2Gu4v2Oyk8hhZS0DRART6g%40mail.gmail.com Thanks, Lukas -- Lukas Fittl

Sampling-based timing for EXPLAIN ANALYZE

the idea, collaborating on early code and finding the approach to hook into the timeout API. Thanks, Lukas -- Lukas Fittl v1-0001-Add-TIMING-SAMPLING-option-for-EXPLAIN-ANALYZE.patch Description: Binary data

Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)

t would be good to explain the different values for "io_strategy" (and what they mean) - Overall it would be helpful if we had a dedicated documentation page on I/O statistics that's linked from the pg_stat_io view description, and explains how the I/O statistics tie into the various concepts of shared buffers / buffer access strategies / etc (and what is not tracked today) Thanks, Lukas -- Lukas Fittl

Re: pg_get_constraintdef: Schema qualify foreign tables unless pretty printing is enabled

to get_*_query_def functions * Update pg_get_triggerdef_worker to handle pretty for FROM as well If that seems like a sensible direction I'd be happy to work on a patch. Thanks, Lukas -- Lukas Fittl

pg_get_constraintdef: Schema qualify foreign tables unless pretty printing is enabled

--- FOREIGN KEY (b) REFERENCES foo(a) PRIMARY KEY (a) PRIMARY KEY (a) (3 rows) Thanks, Lukas -- Lukas Fittl From 83a1ab6081f70d0eed820b2b13bc3ab6e93af8ec Mon Sep 17 00:00:00 2001 From: Lukas Fittl Date: Tue, 9 Aug 2022 16:55:35 -0700 Subject: [PATCH v1] pg_get_constraintdef: Schema qualify

Re: log_line_prefix: make it possible to add the search_path

. "non_default" would output the search path when a SET has modified it in the current session (and so we couldn't infer it from the config or the role/database overrides). "always" would always output the search path for statement-related log lines. Thanks, Lukas -- Lukas Fittl

Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?

thub.com/torvalds/linux/blob/master/arch/x86/kernel/tsc.c [2] http://oliveryang.net/2015/09/pitfalls-of-TSC-usage/ [3] https://stackoverflow.com/a/11060619/1652607 [4] https://cpufun.substack.com/p/fun-with-timers-and-cpuid -- Lukas Fittl v2-0002-WIP-Use-cpu-reference-cycles-via-rdtsc-to-measure.pa

Re: shared-memory based stats collector - v70

a new snapshot to be built > + or (when in cache mode) accessed statistics to be cached. > Ah, yes, that does clarify what was meant. +1 to Justin's edit, or something like it. Thanks, Lukas -- Lukas Fittl

Re: shared-memory based stats collector - v70

and "The" (not sure if that matters) > + next use of statistical information will cause a new snapshot to be built > + or accessed statistics to be cached. I believe this should be an "and", not an "or". (next access builds both a new snapshot and caches accessed statistics) Thanks, Lukas -- Lukas Fittl

Re: [PATCH] Add extra statistics to explain for Nested Loop

ere provided, I wonder if even a simple pgbench with auto_explain (and log_analyze=1) would be a way to test this? The overhead of the Instrumentation struct size should show regardless of whether a plan actually includes a Nested Loop. Thanks, Lukas -- Lukas Fittl

Re: PostgreSQL 13 Beta 1 Release Announcement Draft

s. https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=3048898e73c75f54bb259323382e0e7f6368cb6f Thanks, Lukas -- Lukas Fittl

Procedure calls are not tracked in pg_stat_user_functions / track_functions

, we could just track this together with functions, since one can always join with pg_proc to determine whether something is a function or a procedure. Thanks, Lukas -- Lukas Fittl

Re: Query is over 2x slower with jit=on

oved an (I believe) unnecessary "if (estate->es_instrument)" check that prevented EXPLAIN without ANALYZE from showing whether JIT would be used or not. In addition this also updates a missed section in the documentation with the new stats output format. Best, Lukas -- Lukas Fittl fix-ji

Re: auto_explain: Include JIT output if applicable

On Mon, Sep 24, 2018 at 1:48 PM, Andres Freund wrote: > > Thanks for noticing - pushed! > Thanks! Best, Lukas -- Lukas Fittl

auto_explain: Include JIT output if applicable

to auto_explain with the same logic as used for regular EXPLAIN. Thanks, Lukas -- Lukas Fittl auto_explain-include-jit-output-v1.patch Description: Binary data

Re: [HACKERS] Planning counters in pg_stat_statements

as going on earlier. Thomas: I'm not as familiar with planner internals as you are, but happy to try and contribute here. Would it be useful for me to try to adjust the patch to Tom's proposal? Best, Lukas -- Lukas Fittl