Re: More then 1600 columns? - Mailing list pgsql-general
| From | Dmitriy Igrishin |
|---|---|
| Subject | Re: More then 1600 columns? |
| Date | |
| Msg-id | AANLkTinaoL3kBK9Y438dsh9ggkRnSAsKJXQp3eLiaBxK@mail.gmail.com Whole thread Raw |
| In response to | Re: More then 1600 columns? (Pavel Stehule <pavel.stehule@gmail.com>) |
| Responses |
Re: More then 1600 columns?
(Pavel Stehule <pavel.stehule@gmail.com>)
|
| List | 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 !
--
// Dmitriy.
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.stehule@gmail.com>
2010/11/12 Dmitriy Igrishin <dmitigr@gmail.com>:> Hey Peter,there are indexes on arrays - you can use a GiST, Gin indexes.
>
> Unfortunately, there is no indexes on arrays (only on expressions).
regards
Pavel
> With hstore we can easily create GiST index for effective access.
>
> 2010/11/12 Peter Bex <Peter.Bex@xs4all.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@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-general
>
>
>
> --
> // Dmitriy.
>
>
>
--
// Dmitriy.
pgsql-general by date: