Re: Very large tables
От
Grzegorz Jaśkiewicz
Тема
Re: Very large tables
Дата
Msg-id
2f4958ff0811280858s370e7a62x94aa26e1a72f47a7@mail.gmail.com
Ответ на
Re: Very large tables (William Temperley)
Список
Дерево обсуждения
Very large tables "William Temperley" <willtemperley@gmail.com>
Re: Very large tables Simon Riggs <simon@2ndQuadrant.com>
Re: Very large tables "William Temperley" <willtemperley@gmail.com>
Re: Very large tables Alvaro Herrera <alvherre@commandprompt.com>
Re: Very large tables "Grzegorz Jaśkiewicz" <gryzman@gmail.com>
Re: Very large tables "William Temperley" <willtemperley@gmail.com>
Re: Very large tables Alvaro Herrera <alvherre@commandprompt.com>
Re: Very large tables "Grzegorz Jaśkiewicz" <gryzman@gmail.com>
Re: Very large tables Ron Mayer <rm_pg@cheapcomplexdevices.com>
Re: Very large tables Scara Maccai <m_lists@yahoo.it>
2008/11/28 William Temperley <willtemperley@gmail.com>
true, if you don't want to search on values too much ,or at all - use float[]. But otherwise, keep stuff in a tables as such.
It might be humongous in size, but at the end of the day - prime thing when designing a db is speed of queries.
Still, I wouldn't go too far down the 'compress and stick in as bytea' road, cos it is quite slippery, even tho might look shiny at first,
you can also consider vertical partition (separate machines). Honestly, I would try different approaches first, on scaled down data set, but focusing on retrieval/update (well, whatever your applications are going to use it for).
Any more normalized and I'd have 216 billion rows! Add an index and
I'd have - well, a far bigger table than 432 million rows each
containing a float array - I think?
Really I'm worried about reducing storage space and network overhead
- therefore a nicely compressed chunk of binary would be perfect for
the 500 values - wouldn't it?
true, if you don't want to search on values too much ,or at all - use float[]. But otherwise, keep stuff in a tables as such.
It might be humongous in size, but at the end of the day - prime thing when designing a db is speed of queries.
Still, I wouldn't go too far down the 'compress and stick in as bytea' road, cos it is quite slippery, even tho might look shiny at first,
you can also consider vertical partition (separate machines). Honestly, I would try different approaches first, on scaled down data set, but focusing on retrieval/update (well, whatever your applications are going to use it for).
--
GJ
В списке pgsql-general по дате отправления