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

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 (view raw or flat)
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

pgsql-performance by date

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

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