From: | Dimitri <dimitrik(dot)fr(at)gmail(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Equivalents in PostgreSQL of MySQL's "ENGINE=MEMORY" "MAX_ROWS=1000" |
Date: | 2007-04-04 12:46:54 |
Message-ID: | 5482c80a0704040546q7a27e2cdk8ed8307f0ebb39f8@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Probably another helpful solution may be to implement:
ALTER TABLE LOGGING OFF/ON;
just to disable/enable WAL?
First it may help in all cases of intensive data load while you slow
down other sessions with increasing WAL activity.
Then you have a way to implement MEMORY-like tables on RAM disk
tablespace (well, you still need to take care to drop them
auto-manually :))
However, if we speak about performance of MEMORY table - it should be
much better in Tom's solution with big temp buffers rather RAM disk...
The strong point in implementation of MEMORY table is it *knows* it
sits in RAM! and it changes completely all I/O kind logic...
BTW, before NDB was bough by MySQL we done a benchmark to rich a
highest possible TPS numbers with it. We got 1.500.000 TPS(!) (yes,
one million and half per second!) knowing all current TPC records are
measured in thousands of transactions per minute - you see impact...
And of course for my education I tried to do the same with other
database vendors running only SELECT queries and placing tablespaces
on RAM disk... After trying all possible combinations I was still
*very* far :))
MEMORY databases is something like a parallel world, very interesting,
but very different :))
Rgds,
-Dimitri
On 4/3/07, A.M. <agentm(at)themactionfaction(dot)com> wrote:
>
> On Apr 3, 2007, at 16:00 , Alan Hodgson wrote:
>
> > On Tuesday 03 April 2007 12:47, "A.M."
> > <agentm(at)themactionfaction(dot)com> wrote:
> >> On Apr 3, 2007, at 15:39 , C. Bergström wrote:
> >> I would like to use transactional semantics over tables that can
> >> disappear whenever the server fails. memcached does not offer that.
> >
> > How would temporary tables?
>
> The only difference between temporary tables and standard tables is
> the WAL. Global temporary tables would be accessible by all sessions
> and would be truncated on postmaster start. For a further potential
> speed boost, global temp tables could be put in a ramdisk tablespace.
>
> Well, that's at least how I envision them.
>
> Cheers,
> M
> ---------------------------(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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2007-04-04 13:19:20 | Re: SCSI vs SATA |
Previous Message | Andreas Kostyrka | 2007-04-04 12:46:43 | Re: SCSI vs SATA |