Re:Sort improvements in PostgreSQL since 1997 [pdf]
by Alexss on Tuesday February 16, 2016 @08:34AM
(#11109658)
It's mentioned, albeit in the second-last line of the whole presentation, as a possible reaction to GPU-based sorting in the future.
[ Parent
| on HN ]
Re:Sort improvements in PostgreSQL since 1997 [pdf]
by Ono-Sendai on Tuesday February 16, 2016 @08:44AM
(#11109714)
Ok. Because you can radix sort on CPU and it's a lot faster than e.g. quicksort in my experience.
Re:Sort improvements in PostgreSQL since 1997 [pdf]
by zkzkz on Wednesday February 17, 2016 @12:58PM
(#11119763)
Postgres has an extensible type system so Radix sort isn't really suitable, it really needs a comparison sort.
For SSE/MMX/AVX/etc or GPU sorts it would have to use integer or floating point surrogate keys. It would probably be the same abbreviated keys mentioned in the last few slides. That could be a radix sort but generally I think bitonic sort is preferred.
Re:Sort improvements in PostgreSQL since 1997 [pdf]
by Jweb_Guru on Friday February 19, 2016 @12:42AM
(#11131838)
> Postgres has an extensible type system so Radix sort isn't really suitable, it really needs a comparison sort.
That's not quite true. It supports string tries, for example (using SP-GIST). Such operations just have to be built for specific types. I think it would be more accurate to say that (AFAICT) Postgres doesn't currently have any way to extend the optimizer with custom plans (though it's been a very popular feature suggestion).
Re:Sort improvements in PostgreSQL since 1997 [pdf]
by anarazel on Friday February 19, 2016 @03:22AM
(#11132329)
> I think it would be more accurate to say that (AFAICT) Postgres doesn't currently have any way to extend the optimizer with custom plans (though it's been a very popular feature suggestion).
There's http://www.postgresql.org/docs/devel/static/custom-scan.html