Thank you very much, Tom
I will try vector 'parallel' and 'vertical' strategies.
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,
> > - It's posible to tune some TOAST parameters to get faster atomic
> > 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
Tol Development Team member
In response to
pgsql-performance by date
|Next:||From: Chris Browne||Date: 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|