Re: B-Tree support function number 3 (strxfrm() optimization)
| От | Peter Geoghegan |
|---|---|
| Тема | Re: B-Tree support function number 3 (strxfrm() optimization) |
| Дата | |
| Msg-id | CAM3SWZRe5-JizUdvHRiJuZEQY2Va-ddREPEMhosnedvdDVFuJQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: B-Tree support function number 3 (strxfrm() optimization) (Peter Geoghegan <pg@heroku.com>) |
| Ответы |
Re: B-Tree support function number 3 (strxfrm() optimization)
|
| Список | pgsql-hackers |
On Tue, Jan 20, 2015 at 3:57 PM, Peter Geoghegan <pg@heroku.com> wrote: > It's certainly possible to fix Andrew's test case with the attached. > I'm not sure that that's the appropriate fix, though: there is > probably a case to be made for not bothering with abbreviation once > we've read tuples in for the final merge run. More likely, the > strongest case is for storing the abbreviated keys on disk too, and > reading those back. Maybe not, though: An extra 8 bytes per tuple on disk is not free. OTOH, if we're I/O bound on the final merge, as we ought to be, then recomputing the abbreviated keys could make sense, since there may well be an idle CPU core anyway. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: