Re: Storing binary data. - Mailing list pgsql-performance

From Jesper Krogh
Subject Re: Storing binary data.
Date
Msg-id cfdhhd$ft2$1@sea.gmane.org
Whole thread Raw
In response to Storing binary data.  (Jesper Krogh <jesper@krogh.cc>)
Responses Re: Storing binary data.
List 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@krogh.cc
Jabber ID: jesper@jabbernet.dk


pgsql-performance by date:

Previous
From: "Merlin Moncure"
Date:
Subject: Re: Hardware upgrade for a high-traffic database
Next
From: "Merlin Moncure"
Date:
Subject: Re: fsync vs open_sync