Re: [HACKERS] Q about heap_getattr
От | Vadim Mikheev |
---|---|
Тема | Re: [HACKERS] Q about heap_getattr |
Дата | |
Msg-id | 36AB61C9.EB785987@krs.ru обсуждение исходный текст |
Ответ на | Q about heap_getattr (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Q about heap_getattr
Re: [HACKERS] Q about heap_getattr |
Список | pgsql-hackers |
Tom Lane wrote: > > I've been doing some more backend profiling, and observe that in a large > SELECT from a table with lots of columns, nocachegetattr (the guts of > heap_getattr) is at the top of the list, accounting for about 15% of > runtime. > > The percentage would be lower in a table with fewer columns or no null > columns, but it still seems worth working on. (Besides, this case right > here is a real-world case for me.) > > What's drawing my eye is that printtup() is calling heap_getattr twice > for each attribute of each tuple --- once in the first scan that > prepares the null-fields bitmap, and then again to actually output the > field value. So, what I want to do is call heap_getattr only once per > attribute and save the returned value for use in the second loop. > That should halve the time spent in nocachegetattr and thus knock > 7 or so percent off the runtime of SELECT. Try to use heap_attisnull in first scan! This func just tests nulls bitmap array of tuple... Vadim P.S. Tom, I forgot to attach new allocation code in my prev letter, but now I want to reimplement them.
В списке pgsql-hackers по дате отправления: