On 15 February 2012 22:54, Gaetano Mendola <mendola(at)gmail(dot)com> wrote:
> That sounds a bit harsh. I'm one of those indeed, I haven't look in the
> details not having enough time for it. At work we do GPU computing (not
> the sort type stuff) and given the fact I'm a Postgres enthusiast I
> asked my self: "my server is able to sort around 500 milions integer per
> seconds, if postgres was able to do that as well it would be very nice".
> What I have to say? Sorry for my thoughts.
I'm not trying to sound harsh.
The only reason that my patch *nearly* had support for this was
because the implementation that we nearly went with would have only
needed another couple of lines of code to support it. It very probably
wouldn't have turned out to have been useful for any novel sorting
idea, and was really only intended to be used to support user-defined
full sorting specialisations. That didn't end up making the cut.
My point is that whatever is holding back the development of a useful
prototype here, it definitely isn't the lack of an existing API. We
don't know what such an API should look like, and just how invasive it
needs to be. More importantly, it remains to be seen how useful this
idea is in the real world - we don't have so much as a synthetic test
case with a single client, as far as I'm aware.
I'd encourage the OP to share his work on github or something along those lines.
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
In response to
pgsql-hackers by date
|Next:||From: Dann Corbit||Date: 2012-02-16 00:37:40|
|Subject: Re: CUDA Sorting|
|Previous:||From: Peter Geoghegan||Date: 2012-02-16 00:02:48|
|Subject: Re: Progress on fast path sorting, btree index creation time|