On Thursday 05 July 2007 13:52, Joshua D. Drake wrote:
> A.M. wrote:
> > On Jul 5, 2007, at 13:20 , Andrew Sullivan wrote:
> >> On Sun, Jul 01, 2007 at 11:11:30PM +0200, Alexander Todorov wrote:
> >>> The question was is there something else that exists in PostgreSQL and
> >>> will do the same job.
Why not have a table type that writes no WAL and is truncated whenever
postgres starts? Such a table could then be put in a ramdisk tablespace
and there would be no transaction atomicity repercussions. Is there
something I'm missing?
Is this not in the TODO (if not already schedul
A.M. wrote:
On Jul 5, 2007, at 13:20 , Andrew Sullivan wrote:
On Sun, Jul 01, 2007 at 11:11:30PM +0200, Alexander Todorov wrote:
The question was is there something else that exists in PostgreSQL and
will do the same job.
Why not have a table type that writes no WAL and is truncated wheneve
On Jul 5, 2007, at 13:20 , Andrew Sullivan wrote:
On Sun, Jul 01, 2007 at 11:11:30PM +0200, Alexander Todorov wrote:
The question was is there something else that exists in PostgreSQL
and
will do the same job.
Why re-invent the wheel, and make it square? But also, if you don't
care whethe
On Sun, Jul 01, 2007 at 11:11:30PM +0200, Alexander Todorov wrote:
> The question was is there something else that exists in PostgreSQL and
> will do the same job.
Why re-invent the wheel, and make it square? But also, if you don't
care whether you keep your data, why on earth are you putting it
"Alexander Todorov" <[EMAIL PROTECTED]> writes:
> On 7/2/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> 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,
On 7/2/07, Tom Lane <[EMAIL PROTECTED]> wrote:
David Fetter <[EMAIL PROTECTED]> 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.
Thanks for this hint
David Fetter escribió:
> On Sun, Jul 01, 2007 at 03:55:11PM -0400, Alvaro Herrera wrote:
> > Alexander Todorov escribió:
> > > On 7/1/07, Tom Lane <[EMAIL PROTECTED]> 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
David Fetter <[EMAIL PROTECTED]> 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
c
On Sun, Jul 01, 2007 at 03:55:11PM -0400, Alvaro Herrera wrote:
> Alexander Todorov escribió:
> > On 7/1/07, Tom Lane <[EMAIL PROTECTED]> 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
Alexander Todorov escribió:
> On 7/1/07, Alvaro Herrera <[EMAIL PROTECTED]> 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.
Wha
On 7/1/07, Alvaro Herrera <[EMAIL PROTECTED]> 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 broadc
Alexander Todorov escribió:
> On 7/1/07, Tom Lane <[EMAIL PROTECTED]> 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
On 7/1/07, Tom Lane <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> writes:
> On 7/1/07, Tom Lane <[EMAIL PROTECTED]> 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.
>
On 7/1/07, Tom Lane <[EMAIL PROTECTED]> 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 di
"Alexander Todorov" <[EMAIL PROTECTED]> 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
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?
Greet
18 matches
Mail list logo
