Re: [HACKERS] Runtime Partition Pruning
Tomas Vondra <tomas.vondra@2ndquadrant.com>
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Robert Haas <robertmhaas@gmail.com>, David Rowley <david.rowley@2ndquadrant.com>, Amit Langote <amitlangote09@gmail.com>, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, Jesper Pedersen <jesper.pedersen@redhat.com>, Rajkumar Raghuwanshi <rajkumar.raghuwanshi@enterprisedb.com>, Beena Emerson <memissemerson@gmail.com>, amul sul <sulamul@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Dilip Kumar <dilipbalaut@gmail.com>
Date: 2019-05-24T22:42:39Z
Lists: pgsql-hackers
On Fri, May 24, 2019 at 09:24:28AM -0700, Andres Freund wrote: >Hi, > >On 2019-05-24 12:08:57 -0400, Tom Lane wrote: >> Andres Freund <andres@anarazel.de> writes: >> > On 2019-05-24 11:34:58 -0400, Tom Lane wrote: >> >> Hmm, after some digging in the archives, the closest thing I can find >> >> is this thread: >> >> https://www.postgresql.org/message-id/flat/CAMsr%2BYGL%2ByfWE%3DJvbUbnpWtrRZNey7hJ07%2BzT4bYJdVp4Szdrg%40mail.gmail.com >> >> where we discussed using libunwind instead, but people didn't like >> >> the extra dependency. >> >> > Hm, I didn't actually see that much concern about that. I still think we >> > should just go for libunwind. >> >> Is it actually better? > >I've not looked in a while, but I think at some point it was. > > >> The basic problem with backtrace() is that it >> only knows about global functions, and so reports call sites in static >> functions as if they were in whatever global function physically precedes >> the static one. > >Does that depend on whether the program was compiled with >-fno-omit-frame-pointer? At least some distros now compile with frame >pointers enabled, to get reasonably fast perf profiles (at a basically >immeasurable slowdown, on modern-ish CPUs). > I doubt that, because if that was the case we'd not be able to get accurate profiles from perf, no? And AFAICS that's not the case, irrespectedly of whether -fno-omit-frame-pointer is used. > >> I think doing materially better requires depending on >> debug symbols, which (at least in the Red Hat world) aren't going to >> be there in a typical production situation. > >It's still a lot easier to install debug symbols than to attach a >debugger and get a backtrace that way. Especially when the problem is >hard to reproduce. > Right. Debugger requires interaction with a running process, while having it integrated would make that unnecessary. But I think Peter also suggested this might require the ability to selectively enable the backtraces, and I think he's right. I doubt we want to log them for every log message, right? regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Initialize ExprStates once in run-time partition pruning
- 1957f8dabf8d 11.0 landed
-
Add bms_prev_member function
- 5c0675215e15 11.0 landed
-
Support partition pruning at execution time
- 499be013de65 11.0 landed
-
Document partprune.c a little better
- 971d7ddbe19a 11.0 landed
-
Fix crash in pg_replication_slot_advance
- 6f1d723b6359 11.0 cited
-
Add parallel-aware hash joins.
- 1804284042e6 11.0 cited
-
Fix typo.
- 487a0c1518af 11.0 cited
-
Allow --with-bonjour to work with non-macOS implementations of Bonjour.
- 9b9cb3c4534d 11.0 cited
-
Mention need for --no-inc-recursive in rsync command
- 2c74e6c1dcc5 11.0 cited