Re: Storing binary data.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jesper Krogh <jesper(at)krogh(dot)cc>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Storing binary data.
Date: 2004-08-11 16:06:38
Message-ID: 6088.1092240398@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Jesper Krogh <jesper(at)krogh(dot)cc> writes:
> I'd like some advise on storing binary data in the database.

> Currently I have about 300.000 320.000 Bytes "Bytea" records in the
> database. It works quite well but I have a feeling that it actually is
> slowing the database down on queries only related to the surrounding
> attributes.

> The "common" solution, I guess would be to store them in the filesystem
> instead, but I like to have them just in the database it is nice clean
> database and application design and if I can get PostgreSQL to "not
> cache" them then it should be excactly as fast i assume.

> The binary data is not a part of most queries in the database only a few
> explicitly written to fetch them and they are not accessed very often.

> What do people normally do?

Nothing. If the bytea values are large enough to be worth splitting
out, Postgres will actually do that for you automatically. Wide field
values get pushed into a separate "toast" table, and are not fetched by
a query unless the value is specifically demanded.

You can control this behavior to some extent by altering the storage
option for the bytea column (see ALTER TABLE), but the default choice
is usually fine.

If you just want to see whether anything is happening, do a VACUUM
VERBOSE on that table and note the amount of storage in the toast table
as compared to the main table.

regards, tom lane

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Bruno Wolff III 2004-08-11 16:27:01 Re: How to know which queries are to be optimised?
Previous Message Sanjay Arora 2004-08-11 15:47:10 Re: Hardware upgrade for a high-traffic database