Re: [PATCH] Full support for index LP_DEAD hint bits on standby
От | Michail Nikolaev |
---|---|
Тема | Re: [PATCH] Full support for index LP_DEAD hint bits on standby |
Дата | |
Msg-id | CANtu0og_B+Ybsbg_6ekOJrFog21q6o+JK+NP=-6Vww5Zk5E=tA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Full support for index LP_DEAD hint bits on standby (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: [PATCH] Full support for index LP_DEAD hint bits on standby
|
Список | pgsql-hackers |
Hello, Peter. > The simple answer is: I don't know. I could probably come up with a > better answer than that, but it would take real effort, and time. I remember you had an idea about using the LP_REDIRECT bit in btree indexes as some kind of “recently dead” flag (1). Is this idea still in progress? Maybe an additional bit could provide a space for a better solution. > I think that you could do a better job of explaining and promoting the > problem that you're trying to solve here. Emphasis on the problem, not > so much the solution. System I am working on highly depends on the performance of reading from standby. In our workloads queries on standby are sometimes 10-100x slower than on primary due to absence of LP_DEAD support. Other users have the same issues (2). I believe such functionality is great optimization for read replicas with both analytics and OLTP (read-only) workloads. > You must understand that this whole area is *scary*. The potential for > serious data corruption bugs is very real. And because the whole area > is so complicated (it is at the intersection of 2-3 complicated > areas), we can expect those bugs to be hidden for a long time. We > might never be 100% sure that we've fixed all of them if the initial > design is not generally robust. Most patches are not like that. Moved to “Waiting for Author” for now. [1]: https://www.postgresql.org/message-id/flat/CAH2-Wz%3D-BoaKgkN-MnKj6hFwO1BOJSA%2ByLMMO%2BLRZK932fNUXA%40mail.gmail.com#6d7cdebd68069cc493c11b9732fd2040 [2]: https://www.postgresql.org/message-id/flat/20170428133818.24368.33533%40wrigleys.postgresql.org Thanks, Michail.
В списке pgsql-hackers по дате отправления: