Re: Changing SQL Inlining Behaviour (or...?)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Changing SQL Inlining Behaviour (or...?)
Дата
Msg-id 25609.1549237638@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Changing SQL Inlining Behaviour (or...?)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Changing SQL Inlining Behaviour (or...?)  (Paul Ramsey <pramsey@cleverelephant.ca>)
Список pgsql-hackers
I wrote:
> I've posted some preliminary design ideas at
> https://www.postgresql.org/message-id/15193.1548028093@sss.pgh.pa.us
> and
> https://www.postgresql.org/message-id/15289.1548028233@sss.pgh.pa.us
> While there's a nontrivial amount of work needed to make that happen,
> I think it's doable, and it would lead to a significantly better
> solution than proceeding along the inlining path could do.  My
> current feeling, therefore, is that we should reject this patch
> (or at least stick it in the deep freeze) and go work on that plan.

Now that the first of those threads has reached a feature-complete
state, I feel fairly comfortable in saying that we should drop the
idea of messing with the inlining heuristics (at least for the
particular end goal stated in this thread).  So I'm going to go
close this CF entry as returned-with-feedback.

            regards, tom lane


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

Предыдущее
От: Edmund Horner
Дата:
Сообщение: Re: Tid scan improvements
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Ryu floating point output patch