More ideas for speeding up sorting - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject More ideas for speeding up sorting
Date
Msg-id d89aea6d-2b18-f61d-455e-e6790db636d3@iki.fi
Whole thread Raw
Responses Re: More ideas for speeding up sorting
List 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 by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Tuplesort merge pre-reading
Next
From: David Steele
Date:
Subject: Re: PATCH: Exclude additional directories in pg_basebackup