More ideas for speeding up sorting

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема More ideas for speeding up sorting
Дата
Msg-id d89aea6d-2b18-f61d-455e-e6790db636d3@iki.fi
обсуждение исходный текст
Ответы Re: More ideas for speeding up sorting  (Peter Geoghegan <pg@heroku.com>)
Список pgsql-hackers
A few things caught my eye while hacking on the latest round of sorting 
patches. Starting a new thread because these are orthogonal to the 
things discussed on the other threads:

1. SortTuple.tupindex is not used when the sort fits in memory. If we 
also got rid of the isnull1 flag, we could shrink SortTuple from 24 
bytes to 16 bytes (on 64-bit systems). That would allow you to pack more 
tuples into memory, which generally speeds things up. We could for 
example steal the least-significant bit from the 'tuple' pointer for 
that, because the pointers are always at least 4-byte aligned. (But see 
next point)

2. We could easily categorize incoming tuples as the come in, into those 
that have a leading NULL, and others. If we kept them in separate 
arrays, or perhaps grow memtuples from bottom-up for non-NULLs and from 
top-down for NULLs, we wouldn't need to store, or compare, the 'isnull1' 
flag at all, in the quicksort.

3. In the single-Datum case, i.e. tuplesort_begin_datum(), we could just 
keep a counter of how many NULLs we saw, and not store them at all. 
That's quite a special case, but it's simple enough that it might be 
worth it.

I'm not going to pursue these right now, but might be good projects for 
someone.

- Heikki




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Tuplesort merge pre-reading
Следующее
От: David Steele
Дата:
Сообщение: Re: PATCH: Exclude additional directories in pg_basebackup