Re: Atomic access to large arrays

Поиск
Список
Период
Сортировка
От Victor de Buen
Тема Re: Atomic access to large arrays
Дата
Msg-id f432ce640907220730s6974801m339e4ac81f6adeff@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Atomic access to large arrays  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
Thank you very much, Tom

I will try vector 'parallel' and 'vertical' strategies.

Regards

2009/7/22 Tom Lane <tgl@sss.pgh.pa.us>
"Victor de Buen (Bayes)" <vdebuen@bayesinf.com> writes:
> I'm storing historical meteorological gridded data from GFS (
> http://www.nco.ncep.noaa.gov/pmb/products/gfs/) into an array field in a
> table like this:

>   vl_grid smallint[361][720],

>    - It's posible to tune some TOAST parameters to get faster atomic access
>    to large arrays?

It might save a little bit to make the toast chunk size larger, but I'm
not sure you could gain much from that.

>    - Using "EXTERNAL" strategy for storing TOAST-able columns could solve
>    the problem?

Nope, wouldn't help --- AFAIR array access is not optimized for slice
access.  In any case, doing that would give up the compression savings
that you were so happy about.

If your normal access patterns involve "vertical" rather than
"horizontal" scans of the data, maybe you should rethink the choice
of table layout.  Or maybe the compression is enough to allow you
to consider storing the data twice, once in the current layout and
once in a "vertical" format.

                       regards, tom lane



--
Víctor de Buen Remiro
Consultor estadístico
Bayes Forecast
www.bayesforecast.com
Tol Development Team member
www.tol-project.org

В списке pgsql-performance по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Atomic access to large arrays
Следующее
От: "Greg Sabino Mullane"
Дата:
Сообщение: Re: Master/Slave, DB separation or just spend $$$?