SEO

Hello,
is there anything to emulate the MySQL memory table engine?
A straight forward solution is to create a ramfs volume and mount/link
content under /var/lib/postresql there. Then add some scripts to
save/restore databases when the server restarts.
I am wondering is there something else?

Greetings,
Alexander

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org/

"Alexander Todorov" <alexx.todorov@gmail.com> writes:
> is there anything to emulate the MySQL memory table engine?
> A straight forward solution is to create a ramfs volume and mount/link
> content under /var/lib/postresql there. Then add some scripts to
> save/restore databases when the server restarts.
> I am wondering is there something else?

As long as shared_buffers is high enough, there doesn't seem to be much
point in worrying about this; the incremental performance gain will be
minimal since everything will be in RAM anyway. Or do you think losing
the content of the database at server crash is a feature?

regards, tom lane

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

http://www.postgresql.org/docs/faq

On 7/1/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> As long as shared_buffers is high enough, there doesn't seem to be much
> point in worrying about this; the incremental performance gain will be
> minimal since everything will be in RAM anyway.

Yes it will be but this does not mean there will be no disk i/o
operations. Database contents still have to be backed up on disk
(unless there is a mechanism of delayed wrtite to disk which I am not
aware of). The memory engine as designed by MySQL (my interpretation)
is to avoid the disk operations.

> Or do you think losing
> the content of the database at server crash is a feature?

Yes it is. Anything designed to live in memory should be used to hold
non vital information. The loosing/recreation of this information is
implied by design of the application.
One example is bittorent trackers which maintain data about the
connected peers. Since connections are created/destroyed and there are
more selects than insert/updates these applications use memory tables.

Greetings,
Alexander.

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org/

"Alexander Todorov" <alexx.todorov@gmail.com> writes:
> On 7/1/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> As long as shared_buffers is high enough, there doesn't seem to be much
>> point in worrying about this; the incremental performance gain will be
>> minimal since everything will be in RAM anyway.

> Yes it will be but this does not mean there will be no disk i/o
> operations. Database contents still have to be backed up on disk
> (unless there is a mechanism of delayed wrtite to disk which I am not
> aware of).

It's called a checkpoint.

Assuming that you would actually like your changes to get saved
someplace, I doubt you are going to be able to improve efficiency
by replacing the existing write mechanisms by some ad-hoc
application-level backup procedure. That's why I asked if you
thought losing data at crash was a feature, as opposed to a severe
demerit that you put up with in the hope of gaining some performance
--- because unless that's what you think, it's probably not a real
useful path to pursue.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On 7/1/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> That's why I asked if you thought losing data at crash was a feature
Yes it is. I don't want to actually save the data on disk.

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Alexander Todorov escribió:
> On 7/1/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >That's why I asked if you thought losing data at crash was a feature
> Yes it is. I don't want to actually save the data on disk.

So mount a ramdisk and initdb in there.

--
Alvaro Herrera http://www.flickr.com/photos/alvherre/
"El hombre nunca sabe de lo que es capaz hasta que lo intenta" (C. Dickens)

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On 7/1/07, Alvaro Herrera <alvherre@commandprompt.com> wrote:
> So mount a ramdisk and initdb in there.

As I wrote in my first post that is the straight forward approach.
The question was is there something else that exists in PostgreSQL and
will do the same job.

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org/

Alexander Todorov escribió:
> On 7/1/07, Alvaro Herrera <alvherre@commandprompt.com> wrote:
> >So mount a ramdisk and initdb in there.
>
> As I wrote in my first post that is the straight forward approach.
> The question was is there something else that exists in PostgreSQL and
> will do the same job.

What for, already there being a way?

--
Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J
"The important things in the world are problems with society that we don't
understand at all. The machines will become more complicated but they won't
be more complicated than the societies that run them." (Freeman Dyson)

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

On Sun, Jul 01, 2007 at 03:55:11PM -0400, Alvaro Herrera wrote:
> Alexander Todorov escribió:
> > On 7/1/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > >That's why I asked if you thought losing data at crash was a
> > >feature
> > Yes it is. I don't want to actually save the data on disk.
> So mount a ramdisk and initdb in there.

You could also put a tablespace on a ramdisk and create the table
there.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter

Remember to vote!
Consider donating to PostgreSQL: http://www.postgresql.org/about/donate

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org/

David Fetter <david@fetter.org> writes:
> On Sun, Jul 01, 2007 at 03:55:11PM -0400, Alvaro Herrera wrote:
>> So mount a ramdisk and initdb in there.

> You could also put a tablespace on a ramdisk and create the table
> there.

The fresh-initdb approach is more likely to work without any strange
corner cases. If you try a setup where the system catalogs are on
persistent storage but you have a tablespace on ramdisk, then after
restart you'll have pg_class entries referencing files that don't exist
anymore, which I believe will provoke errors.

Also, I doubt the OP wants his WAL on real storage either ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match