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, [EMAIL PROTECTED]
Jabber ID: [EMAIL PROTECTED]



---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faqs/FAQ.html

Reply via email to