----- Цитат от Robert Haas (robertmhaas@gmail.com), на 16.09.2014 в 22:20 -----
>
> In practice, I'm not very surprised that the impact doesn't seem too
> bad when you're running SQL queries from the client. There's so much
> other overhead, for de-TOASTing and client communication and even just
> planner and executor costs, that this gets lost in the noise. But
> think about a PL/pgsql procedure, say, where somebody might loop over
> all of the elements in array. If those operations go from O(1) to
> O(n), then the loop goes from O(n) to O(n^2). I will bet you a
> beverage of your choice that somebody will find that behavior within a
> year of release and be dismayed by it.
>
Hi,
I can imagine situation exactly like that. We could use jsonb object to
represent sparse vectors in the database where the key is the dimension
and the value is the value. So they could easily grow to thousands of
dimensions. Once you have than in the database it is easy to go and
write some simple numeric computations on these vectors, let's say you
want a dot product of 2 sparse vectors. If the random access inside one
vector is going to O(n^2) then the dot product computation will be going
to O(n^2*m^2), so not pretty.
I am not saying that the DB is the right place to do this type of
computations but it is somethimes convenient to have it also in the DB.
Regards,
luben