On Fri, Apr 16, 2010 at 11:28:36AM -0400, Merlin Moncure wrote:
> If you are storing big data and want to keep the overhead low, the
> first thing you need to examine is organizing your data into arrays.
> This involves tradeoffs of course and may not work but it's worth a
> shot!
That does sound
On Fri, Apr 16, 2010 at 12:40:21PM +0200, Szymon Guz wrote:
> I thought that the default fillfactor was much smaller (and haven't checked
> that now)... sorry for messing that up.
> But let's think of it from the other side: what do you want to do with that
> data? Maybe PostgreSQL with it's MVCC'
On Fri, Apr 16, 2010 at 5:41 AM, Peter Bex wrote:
> Hi all,
>
> I have a table with three columns: one integer and two doubles.
> There are two indexes defined (one on the integer and one on one
> of the doubles). This table stores 70 records, which take up
> 30 Mb according to pg_relation_si
Richard Huxton writes:
> On 16/04/10 10:41, Peter Bex wrote:
>> Is there a way to reduce the per-tuple storage overhead?
> Short answer - no.
About the only thing you could really do is rethink the table layout.
If you can put more data per row, then the fractional overhead for
tuple headers nat
On 16/04/10 10:41, Peter Bex wrote:
Hi all,
I have a table with three columns: one integer and two doubles.
There are two indexes defined (one on the integer and one on one
of the doubles). This table stores 70 records, which take up
30 Mb according to pg_relation_size(), and the total rela
2010/4/16 Peter Bex
> On Fri, Apr 16, 2010 at 11:59:38AM +0200, Szymon Guz wrote:
> > File pages are not fully filled from the start as that could result in
> bad
> > performance of queries later.
>
> The manual page you linked to says something else:
> "The fillfactor for a table is a percentage
On Fri, Apr 16, 2010 at 11:59:38AM +0200, Szymon Guz wrote:
> File pages are not fully filled from the start as that could result in bad
> performance of queries later.
The manual page you linked to says something else:
"The fillfactor for a table is a percentage between 10 and 100.
100 (complete
2010/4/16 Peter Bex
> Hi all,
>
> I have a table with three columns: one integer and two doubles.
> There are two indexes defined (one on the integer and one on one
> of the doubles). This table stores 70 records, which take up
> 30 Mb according to pg_relation_size(), and the total relation
Hi all,
I have a table with three columns: one integer and two doubles.
There are two indexes defined (one on the integer and one on one
of the doubles). This table stores 70 records, which take up
30 Mb according to pg_relation_size(), and the total relation size
is 66 Mb.
I expected the di
