From: | Dmitriy Igrishin <dmitigr(at)gmail(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: More then 1600 columns? |
Date: | 2010-11-12 08:20:35 |
Message-ID: | AANLkTinaoL3kBK9Y438dsh9ggkRnSAsKJXQp3eLiaBxK@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Well, it's possible to create GIN indexes on arrays of built-in data types
without extra efforts, because of "GIN" access method has defaul
operator class. But it's not true for GiST:
SELECT am.amname AS index_method, opc.opcname AS opclass_name
FROM pg_am am, pg_opclass opc
WHERE opc.opcmethod = am.oid AND am.amname = 'gist'
ORDER BY index_method, opclass_name;
gist | box_ops
gist | circle_ops
gist | point_ops
gist | poly_ops
gist | tsquery_ops
gist | tsvector_ops
With hstore I don't need to care about it at all.
But thank you very much to points me about indexes on arrays !
2010/11/12 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> 2010/11/12 Dmitriy Igrishin <dmitigr(at)gmail(dot)com>:
> > Hey Peter,
> >
> > Unfortunately, there is no indexes on arrays (only on expressions).
>
> there are indexes on arrays - you can use a GiST, Gin indexes.
>
> regards
>
> Pavel
>
>
> > With hstore we can easily create GiST index for effective access.
> >
> > 2010/11/12 Peter Bex <Peter(dot)Bex(at)xs4all(dot)nl>
> >>
> >> On Fri, Nov 12, 2010 at 10:17:50AM +0300, Dmitriy Igrishin wrote:
> >> > Hey Mark,
> >> >
> >> > Yeah, I can't imagine an entity in a real project even with more than
> >> > 100
> >> > columns. Its rare case.
> >> > But if you entities (rows/tuples) of some class (table) can contains
> >> > variable
> >> > set of columns (properties) you can look at hstore contrib module.
> >>
> >> What can also work extremely well is storing the data in an array.
> >> If you need to access the array based on more meaningful keys you could
> >> store key/index pairs in another table.
> >>
> >> This approach only works well if you have multiple arrays with the same
> >> layout. You probably also need to build up your query dynamically if
> >> you need to access variable numbers of datapoints.
> >>
> >> Cheers,
> >> Peter
> >> --
> >> http://sjamaan.ath.cx
> >> --
> >> "The process of preparing programs for a digital computer
> >> is especially attractive, not only because it can be economically
> >> and scientifically rewarding, but also because it can be an aesthetic
> >> experience much like composing poetry or music."
> >> -- Donald Knuth
> >>
> >> --
> >> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> >> To make changes to your subscription:
> >> http://www.postgresql.org/mailpref/pgsql-general
> >
> >
> >
> > --
> > // Dmitriy.
> >
> >
> >
>
--
// Dmitriy.
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2010-11-12 08:30:14 | Re: More then 1600 columns? |
Previous Message | Dmitriy Igrishin | 2010-11-12 08:02:08 | Re: More then 1600 columns? |