Re: [HACKERS] Runtime Partition Pruning

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Runtime Partition Pruning
Дата
Msg-id 17881.1558714137@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Runtime Partition Pruning  (Andres Freund <andres@anarazel.de>)
Ответы Re: [HACKERS] Runtime Partition Pruning  (Andres Freund <andres@anarazel.de>)
Re: [HACKERS] Runtime Partition Pruning  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
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?  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.  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.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Runtime Partition Pruning
Следующее
От: didier
Дата:
Сообщение: Re: [HACKERS] Small fix: avoid passing null pointers to memcpy()