I wrote:
> I think we should replace the whole mess with, say, uint32 for float and
> UINT_MAX for infinity. That will be more portable, probably faster, and
> it will work correctly up to substantially *larger* peak distances than
> the existing code.
After studying the logic a bit more, I realized that the "finite"
distances computed by the algorithm can actually never exceed u_size,
which we're already constraining to be less than SHRT_MAX so that the
adjacency arrays can be "short". So I made it use "short" storage for
distances too, with SHRT_MAX as the infinity value. If we ever find a
need to work with graphs exceeding 32K nodes, it will be trivial to
s/short/int/g in this code.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
