Skip site navigation (1) Skip section navigation (2)

Re: Atomic access to large arrays

From: Victor de Buen <vdebuen(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Atomic access to large arrays
Date: 2009-07-22 14:30:43
Message-ID: f432ce640907220730s6974801m339e4ac81f6adeff@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
Thank you very much, Tom

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

Regards

2009/7/22 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>

> "Victor de Buen (Bayes)" <vdebuen(at)bayesinf(dot)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

In response to

pgsql-performance by date

Next:From: Chris BrowneDate: 2009-07-22 16:25:20
Subject: Re: Master/Slave, DB separation or just spend $$$?
Previous:From: Victor de Buen (Bayes)Date: 2009-07-22 14:27:34
Subject: Re: Atomic access to large arrays

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group