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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Browne | 2009-07-22 16:25:20 | Re: Master/Slave, DB separation or just spend $$$? |
Previous Message | Victor de Buen (Bayes) | 2009-07-22 14:27:34 | Re: Atomic access to large arrays |