Thanks for everyone's help and thoughts on this issue.
My findings on Windows 7 Pro 64 using a PCI based SSD is that for my
smallish image the BLOBs were faster than individual files.
Basically, in line with a table that someone posted earlier in this
thread.
After many experiments, with many var
I'm not sure exactly what you're asking here, but if the question is
whether to use database blobs vs files, then you might be interested in
this technical report from Microsoft:
arxiv.org/ftp/cs/papers/0701/0701168.pdf
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
On Fri, 29 Mar 2013 15:17:52 -0400
Jeff Archer wrote:
> I have previously made an apparently bad assumption about this so now I
> would like to go back to the beginning of the problem and ask the most
> basic question first without any preconceived ideas.
>
> This use case is from an image proce
Those measurements asume that you store each blob in a seperate file. So
the raw file access seems slower for smaller blob sizes.
If you use external blob storage do it in raw clusters like i suggested
in a previous post (size limit 32/64 MB) and store your blobs on page
boundaries (page size
On 29.03.2013 20:17, Jeff Archer wrote:
I have previously made an apparently bad assumption about this so now I
would like to go back to the beginning of the problem and ask the most
basic question first without any preconceived ideas.
This use case is from an image processing application. I ha
On Fri, Mar 29, 2013 at 8:17 PM, Jeff Archer <
jsarc...@nanotronicsimaging.com> wrote:
> I could write directly to a file myself. But I would need to provide some
> minimal indexing, some amount of housekeeping to manage variable
> sized BLOBS and some minimal synchronization so that multiple ins
In case you haven't seen this: http://www.sqlite.org/intern-v-extern-blob.html
On Friday, 29 March, 2013 at 13:52, Jeff Archer wrote:
> On Fri, Mar 29, 2013 at 4:46 PM, Richard Hipp (mailto:d...@sqlite.org)> wrote:
> > On Fri, Mar 29, 2013 at 4:41 PM, Michael Black > (mailto:mdblac...@yahoo.c
On Fri, Mar 29, 2013 at 4:46 PM, Richard Hipp wrote:
> On Fri, Mar 29, 2013 at 4:41 PM, Michael Black wrote:
>
>> I think many people would tell you not to store your images in your
>> database.
>> Just store a filepath to them.
>> That will speed things up quite a bit and even possibly prevent h
On Fri, Mar 29, 2013 at 4:41 PM, Michael Black wrote:
> I think many people would tell you not to store your images in your
> database.
> Just store a filepath to them.
> That will speed things up quite a bit and even possibly prevent having to
> use an SSD.
>
> With the filepath your processing
I think many people would tell you not to store your images in your
database.
Just store a filepath to them.
That will speed things up quite a bit and even possibly prevent having to
use an SSD.
With the filepath your processing apps can use file locking too if you need
it.
-Original Message
Pavel Ivanov wrote:
> On Fri, Mar 29, 2013 at 12:17 PM, Jeff Archer
> wrote:
>> I have previously made an apparently bad assumption about this so now I
>> would like to go back to the beginning of the problem and ask the most
>> basic question first without any preconceived ideas.
>>
>> This use
On Fri, Mar 29, 2013 at 12:17 PM, Jeff Archer
wrote:
> I have previously made an apparently bad assumption about this so now I
> would like to go back to the beginning of the problem and ask the most
> basic question first without any preconceived ideas.
>
> This use case is from an image processi
On 29 Mar 2013, at 7:17pm, Jeff Archer wrote:
> This use case is from an image processing application. I have a large
> amount of intermediate data (way exceeds physical memory on my 24GB
> machine). So, I need to store it temporarily on disk until getting to next
> phase of processing. I am
13 matches
Mail list logo
