Hi Tim,
Off the top of my head, from somewhat left field, using filesystems to
mana=
ge this sort of effect.
Would "real" tables in a tablespace defined on a ramdisk meet this need?
So=
the functionality/accessibility of a=20
physical table is provided, along with the performance of a filesystem
actu=
ally residing in memory. Presumeably viable if you have the memory to
spare=
& know the size of the temp tables won't exceed this.
You could also mount a tablespace on a physical disk with a filesystem
whic=
h has delayed/deferred writes to disk, so that if it is created & deleted
q=
uickly enough, it is never actually written to disk, but just generally
sit=
s in the cache.=20
Cheers,
Brent Wood
>>> Bill Moran <wmoran@[EMAIL PROTECTED]
> 06/06/08 8:01 AM >>>
In response to Tim Tassonis <timtas@[EMAIL PROTECTED]
>:
>=20
> Bill Moran wrote:
> > In response to Tim Tassonis <timtas@[EMAIL PROTECTED]
>:
> >=20
> >>
> >> Now, with apache/php in a mpm environment, I have no guarantee that
a=
=20
> >> user will get the same postgresql session for a subsequent request,
th=
us=20
> >> he will not see the tem****ary table.
> >>
> >> Is there a way to create tem****ary tables in another way, so they
are=
=20
> >> visible between sessions, or do I need to create real tables for
my=20
> >> purpose? And is the perfomance penalty big for real tables, as they
ha=
ve=20
> >> been written to disk/read from disk?
> >=20
> > Build a framework that creates the tables in a special schema, and
then
> > can access them through any session. Use some method to generate
unique
> > table names and store the names in the HTTP session. Create some sort
> > of garbage collection routines that removes tables when they're no
long=
er
> > needed.
> >=20
> > The details of exactly how you pull this off are going to depend
heavily
> > on the rest of your application architecture.
> >=20
>=20
> What you describe is what I referred to as "create real tables". I've=20
> done that and it works, but I wondered if there's something similar=20
> built in postgres apart from classical tem****ary tables.
Not that I'm aware of.
If you keep the mailing list in the CC, others can answer as well.
--=20
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
wmoran@[EMAIL PROTECTED]
412-422-3463x4023
--=20
Sent via pgsql-general mailing list (pgsql-general@[EMAIL PROTECTED]
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
--=20
Sent via pgsql-general mailing list (pgsql-general@[EMAIL PROTECTED]
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
|
