Thread: Is ramdisk usefull ?
Hello everybody,
--
There is message from Tom Lane (2008 !) about ramdisk:
<begin />
> So, IMHO, saying "trust your OS + PostgreSQL" is not a 100% perfect > approach for the people who are asking to keep their objects on RAM, > even though I know that there is nothing we can say right now. Well, nothing is a 100% solution. But my opinion is that people who think they are smarter than an LRU caching algorithm are typically mistaken. If the table is all that heavily used, it will stay in memory just fine. If it's not sufficiently heavily used to stay in memory according to an LRU algorithm, maybe the memory space really should be spent on something else. Now there are certainly cases where a standard caching algorithm falls down --- the main one I can think of offhand is where you would like to give one class of queries higher priority than another, and so memory space should preferentially go to tables that are needed by the first class. But if that's your problem, "pin these tables in memory" is still an awfully crude solution to the problem. I'd be inclined to think instead about a scheme that lets references made by higher-priority queries bump buffers' use-counts by more than 1, or some other way of making the priority considerations visible to an automatic cache management algorithm. regards, tom lane
<end />
I'm working on a migration project (IDS2 to Postgresql) for a big organisation in Belgium.
We need a very quick access to a postgresql table. I did some tests with and without using a ramdisk, and I noticed that requests are smarter using the ramdisk (context: more than 1,000k reads a day and only 5 or 6 writes a day).
Is this message up-to-date ? Can you confirm me that's better to let work the engine of postgresql ? Is there another solution to give more or less priority to a request or a table ?
Giving less priority to a request is also interesting me because we need to launch big batch request. My first idea was to create a slave server using streaming replication. Maybe there is another solution... ?
Best Regards,
Gilles Fauvie
Gilles Fauvie - Open Source Consultant
Email: gfauvie@integer.be
LinkedIn: http://be.linkedin.com/in/fauviegilles
INTEGER SPRL/BVBA
P. +32 (0)67 88 36 13 | F. +32 (0)67 47 52 04
http://www.integer.be | Email: customercare@integer.be
To contact our technical support, we highly recommend that you use the email address customercare@integer.be. This will help us save time and we can respond more quickly to your questions.
Pour contacter notre support technique, nous recommandons grandement que vous utilisiez l'adresse email customercare@integer.be. Cela nous aidera à gagner du temps et nous pourrons répondre plus vite à vos questions.