From: | my ho <mthoatbanjo(at)yahoo(dot)com> |
---|---|
To: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: postgresql performance with multimedia |
Date: | 2004-08-27 06:27:16 |
Message-ID: | 20040827062716.4092.qmail@web54106.mail.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hi,
> For your "streaming" purposes I strongly recommend
> you do it in your
> application with the appropriate thread model. A
> relational database
> management system is not a multimedia cache.
That's actually what i plan to do with postgreSQL,
maybe tailor it to suit with a multimedia streaming
database. Well, i could do it in the application level
but i think it's also worth a try with the database
itself.
> They are only stored in that way on initial load and
> if the load is done
> with a single process. And don't you rely on this
> for the future. Right
> now, if you ever update or delete tuples, that order
> changes already.
does the buffer manager have any idea what table that
buf belongs to? (can we add 'rel' variable to sbufdesc
in buf_internals.h and update it everytime we add new
entry to the buffer cahe?) And then we take in to
account which relation the data in the buffer belongs
to in the buf replacement algorithm or in the
read-ahead policy.
> Also keep in mind that large values are not stored
> inline, but in an
> extra "TOAST" relation.
This is how i store my video file: break them in to
small chunks and store each part in a row of a table.
regards,
MThi
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
From | Date | Subject | |
---|---|---|---|
Next Message | Stefano Bonnin | 2004-08-27 06:57:43 | Query performance issue with 8.0.0beta1 |
Previous Message | Bruce Momjian | 2004-08-27 04:35:07 | Re: Equivalent praxis to CLUSTERED INDEX? |