Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap |
| Дата | |
| Msg-id | 15614.1334695376@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap (Greg Stark <stark@mit.edu>) |
| Список | pgsql-hackers |
Greg Stark <stark@mit.edu> writes:
> On Tue, Apr 17, 2012 at 5:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> This has been discussed before, but it always seemed that the
>> cost-benefit ratio was exceedingly questionable. �You don't get any
>> savings whatsoever unless you reduce the size of the null bitmap across
>> a MAXALIGN boundary, which more and more often is 64 bits, so that the
>> frequency with which the optimization wins anything doesn't look likely
>> to be that high.
> There is the usage pattern where (brace yourself) people have
> thousands of columns in which they have all but a handful be null.
> They might be pretty happy about this.
Oh, I don't doubt that there are *some* use cases for this. I'm just
dubious about how much we'd be slowing things down for everybody else.
As I said, what I'd like to see are some benchmarks, and not just
benchmarks that are tuned to match the sort of case where this wins.
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера