Re: Storing binary data.

From: Jesper Krogh <jesper(at)krogh(dot)cc>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Storing binary data.
Date: 2004-08-11 16:29:33
Message-ID: cfdhhd$ft2$1@sea.gmane.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

I gmane.comp.db.postgresql.performance, skrev Shridhar Daithankar:
> On Wednesday 11 Aug 2004 7:59 pm, Jesper Krogh wrote:
> > 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.
>
> You can normalize them so that a table contains an id and a bytea column only.
> Te main table will contain all the other attributes and a mapping id. That
> way you will have only the main table cached.
>
> You don't have to go to filesystem for this, I hope.

Further benchmarking.

I tried to create a table with the excact same attributes but without
the binary attribute. It didn't change anything, so my idea that it
should be the binary-stuff that sloved it down was wrong.

I have a timestamp column in the table that I sort on. Data is ordered
over the last 4 years and I select based on a timerange, I cannot make
the query-planner use the index on the timestamp by itself but if I "set
enable_seqscan = false" the query time drops by 1/3 (from 1.200 msec to
about 400 msec).

I cannot figure out why the query-planner chooses wrong.
NB: It's postgresql 7.4.3

--
./Jesper Krogh, jesper(at)krogh(dot)cc
Jabber ID: jesper(at)jabbernet(dot)dk

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Merlin Moncure 2004-08-11 16:37:10 Re: fsync vs open_sync
Previous Message Bruno Wolff III 2004-08-11 16:27:01 Re: How to know which queries are to be optimised?