Re: B-Tree support function number 3 (strxfrm() optimization)
От | Tom Lane |
---|---|
Тема | Re: B-Tree support function number 3 (strxfrm() optimization) |
Дата | |
Msg-id | 24287.1396583086@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: B-Tree support function number 3 (strxfrm() optimization) (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: B-Tree support function number 3 (strxfrm() optimization)
Re: B-Tree support function number 3 (strxfrm() optimization) |
Список | pgsql-hackers |
Peter Geoghegan <pg@heroku.com> writes: > I think that those are objectively very large reductions in a cost > that figures prominently in most workloads. Based solely on those > facts, but also on the fairly low complexity of the patch, it may be > worth considering committing this before 9.4 goes into feature freeze, Personally, I have paid no attention to this thread and have no intention of doing so before feature freeze. There are three dozen patches at https://commitfest.postgresql.org/action/commitfest_view?id=21 that have moral priority for consideration for 9.4. Not all of them are going to get in, certainly, and I'm already feeling a lot of guilt about the small amount of time I've been able to devote to reviewing/committing patches this cycle. Spending time now on patches that didn't even exist at the submission deadline feels quite unfair to me. Perhaps I shouldn't lay my own guilt trip on other committers --- but I think it would be a bad precedent to not deal with the existing patch queue first. regards, tom lane
В списке pgsql-hackers по дате отправления: