Re: [HACKERS] Runtime Partition Pruning - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: [HACKERS] Runtime Partition Pruning
Date
Msg-id 20190524224239.jnzgkszsuaxwnvji@development
Whole thread Raw
In response to Re: [HACKERS] Runtime Partition Pruning  (Andres Freund <andres@anarazel.de>)
Responses Re: [HACKERS] Runtime Partition Pruning
List 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 



pgsql-hackers by date:

Previous
From: Ashwin Agrawal
Date:
Subject: Re: Zedstore - compressed in-core columnar storage
Next
From: Tomas Vondra
Date:
Subject: Re: POC: GROUP BY optimization