Re: index structure for 114-dimension vector

Поиск
Список
Период
Сортировка
Искать
От
C Storm
Тема
Re: index structure for 114-dimension vector
Дата
Msg-id
1177350571.162300.296770@b75g2000hsg.googlegroups.com
Ответ на
Список
Дерево обсуждения
Basic Q on superfluous primary keys "Kynn Jones" <kynnjo@gmail.com>
Re: Basic Q on superfluous primary keys Bill Moran <wmoran@collaborativefusion.com>
Re: Basic Q on superfluous primary keys "Merlin Moncure" <mmoncure@gmail.com>
Re: Basic Q on superfluous primary keys "Craig A. James" <cjames@modgraph-usa.com>
Re: Basic Q on superfluous primary keys Ron Mayer <rm_pg@cheapcomplexdevices.com>
Re: Basic Q on superfluous primary keys "Merlin Moncure" <mmoncure@gmail.com>
Re: Basic Q on superfluous primary keys Greg Smith <gsmith@gregsmith.com>
Re: Basic Q on superfluous primary keys "Merlin Moncure" <mmoncure@gmail.com>
Re: Basic Q on superfluous primary keys "Dave Dutcher" <dave@tridecap.com>
Re: Basic Q on superfluous primary keys "Merlin Moncure" <mmoncure@gmail.com>
index structure for 114-dimension vector Andrew Lazarus <andrew@pillette.com>
Re: index structure for 114-dimension vector Jeff Davis <pgsql@j-davis.com>
Re: index structure for 114-dimension vector Mark Kirkwood <markir@paradise.net.nz>
Re: index structure for 114-dimension vector Andrew Lazarus <andrew@pillette.com>
Re: index structure for 114-dimension vector Tom Lane <tgl@sss.pgh.pa.us>
Re: index structure for 114-dimension vector Mark Kirkwood <markir@paradise.net.nz>
Re: index structure for 114-dimension vector Arjen van der Meijden <acmmailing@tweakers.net>
Re: index structure for 114-dimension vector C Storm <christian.storm@gmail.com>
Re: index structure for 114-dimension vector "Alexander Staubo" <alex@purefiction.net>
Re: index structure for 114-dimension vector Oleg Bartunov <oleg@sai.msu.su>
Re: index structure for 114-dimension vector Andrew Lazarus <andrew@pillette.com>
Re: index structure for 114-dimension vector "Alexander Staubo" <alex@purefiction.net>
Re: Basic Q on superfluous primary keys "Craig A. James" <cjames@emolecules.com>
Re: Basic Q on superfluous primary keys "Craig A. James" <cjames@modgraph-usa.com>
Re: Basic Q on superfluous primary keys Jeff Davis <pgsql@j-davis.com>
Re: Basic Q on superfluous primary keys Richard Huxton <dev@archonet.com>
Re: Basic Q on superfluous primary keys Greg Smith <gsmith@gregsmith.com>
Re: Basic Q on superfluous primary keys "Merlin Moncure" <mmoncure@gmail.com>
Re: Basic Q on superfluous primary keys "Craig A. James" <cjames@modgraph-usa.com>
On Apr 20, 12:07 pm, and...@pillette.com (Andrew Lazarus) wrote:
> I have a table with 2.5 million real[] arrays. (They are points in a
> time series.) Given a new array X, I'd like to find, say, the 25
> closest to X in some sense--for simplification, let's just say in the
> usualvectornorm. Speed is critical here, and everything I have tried
> has been too slow.
>
> I imported the cube contrib package, and I tried creating an index on
> a cube of the last 6 elements, which are the most important. Then I
> tested the 2.5MM rows for being contained within a tolerance of the
> last 6 elements of X, +/- 0.1 in each coordinate, figuring that would
> be an indexed search (which I CLUSTERED on). I then ran the sort on
> this smaller set. The index was used, but it was still too slow. I
> also tried creating new columns with rounded int2 values of the last 6
> coordinates and made a multicolumn index.
>
> For each X the search is taking about 4-15 seconds which is above my
> target at least one order of magnitude. Absolute numbers are dependent
> on my hardware and settings, and some of this can be addressed with
> configuration tweaks, etc., but first I think I need to know the
> optimum data structure/indexing strategy.
>
> Is anyone on the list experienced with this sort of issue?
>
> Thanks.
> Andrew Lazarus  and...@pillette.com
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faq

Having worked in high dimensional spaces a lot in my career I think
you'll find that there are
mathematical limits in terms of speed.  In practical terms, a seq_scan
will be unavoidable since
on first approximation you are limited to doing an exhaustive search
in 101-dimensional space unless
you make approximations or dimensionality reductions of some kind.

Read up on the Curse of Dimensionality:  http://en.wikipedia.org/wiki/Curse_of_dimensionality

Have you considered dimension reduction techniques such as Singular
Value Decomposition,
Principal Components Analysis, etc.?

В списке pgsql-performance по дате отправления
От: Scott Marlowe
Дата:
От: Sergey Tsukinovsky
Дата:
FAQ