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

; Whilst no specific bad cases were 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: [HACKERS] Planning counters in pg_stat_statements

what was 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

Re: UUID v7

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

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

wing the cache 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

Sampling-based timing for EXPLAIN ANALYZE

refining 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: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?

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

Re: Sampling-based timing for EXPLAIN ANALYZE

ant to sample it's queries at a higher frequency 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: 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: 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: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)

documentation, it 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: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?

similar to rdtsc, see [4]) Thanks, Lukas [1] https://github.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

Re: log_line_prefix: make it possible to add the search_path

uld be "never" (same as today). "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

pg_get_constraintdef: Schema qualify foreign tables unless pretty printing is enabled

pg_get_constraintdef --- 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_constrain

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

_query_def to pass down prettyFlags 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

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

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

auto_explain: Include JIT output if applicable

ation 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: 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

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

x27;ve also removed 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

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: [PATCH] Optionally record Plan IDs to track plan changes for a query

you have a reproducer that shows these two generate the same plan ID? Thanks, Lukas -- Lukas Fittl

Re: [PATCH] Optionally record Plan IDs to track plan changes for a query

to simply move any comments before the field, in each case where we're adding an annotation? Separately I've been thinking how we could best have a discussion/review on whether the jumbling of specific plan struct fields is correct. I was thinking maybe a quick wiki page could be helpful, noting why to jumble/not jumble certain fields? Thanks, Lukas -- Lukas Fittl

Re: [PATCH] Optionally record Plan IDs to track plan changes for a query

tted. > Thanks, appreciate the test and note re: pgident, taking care of that in the next patch refresh. Thanks, Lukas [0]: https://github.com/percona/pg_stat_monitor/blob/main/pg_stat_monitor.c#L730 [1]: https://github.com/percona/pg_stat_monitor/blob/main/pg_stat_monitor.c#L678 -- Lukas Fittl

Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?

org/D121653) Thanks, Lukas -- Lukas Fittl v10-0001-instr_time-Add-INSTR_TIME_SET_SECONDS-INSTR_TIME.patch Description: Binary data v10-0003-Use-time-stamp-counter-to-measure-time-on-Linux-.patch Description: Binary data v10-0002-wip-report-nanoseconds-in-pg_test_timing.patch Description: Binary data

Re: Proposal - Allow extensions to set a Plan Identifier

f.dev this year, would be great to do an unconference session to discuss this further. Thanks, Lukas -- Lukas Fittl

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

tree soon, > so maybe there could be a case for teaching that to emit additional > costing details such as these? > I don't think that addresses the end-user usability sufficiently - from what I gathered "pg_overexplain" was meant for a hacker audience, not DBAs/etc interpreting Postgres plan choices. Thanks, Lukas -- Lukas Fittl

Re: Proposal - Allow extensions to set a Plan Identifier

only keep the jumble conds/funcs that are not defined in core. So based on that workflow I'm not sure turning gen_node_support.pl into a re-usable module would help, but that's just my perspective without having built this out (yet). Thanks, Lukas [0]: https://www.postgresql.org/message-id/flat/CAP53Pkyow59ajFMHGpmb1BK9WHDypaWtUsS_5DoYUEfsa_Hktg%40mail.gmail.com -- Lukas Fittl

Re: query_id: jumble names of temp tables for better pg_stat_statement UX

ferent), to the point that you can't monitor your workload at all anymore. Thanks, Lukas -- Lukas Fittl