From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, Craig James <craig_james(at)emolecules(dot)com>, fabio(dot)lafarcioli(at)molinoalimonti(dot)com, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Number of tables |
Date: | 2009-08-23 00:40:32 |
Message-ID: | 603c8f070908221740u588fc888l581b6b845a99af5b@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, Aug 20, 2009 at 8:38 PM, Alvaro
Herrera<alvherre(at)commandprompt(dot)com> wrote:
> Greg Stark wrote:
>
>> It would be nice to have a solution to that where you could create
>> lightweight temporary objects which belong to an "application session"
>> which can be picked up by a different database connection each go
>> around.
>
> It would be useful:
>
> CREATE SCHEMA session1234 UNLOGGED
> CREATE TABLE hitlist ( ... );
>
> Each table in the "session1234" schema would not be WAL-logged, and
> would be automatically dropped on crash recovery (actually the whole
> schema would be). But while the server is live it behaves like a
> regular schema/table and can be seen by all backends (i.e. not temp)
+1. In fact, I don't even see why the "unlogged" property needs to be
a schema property. I think you could just add a table reloption.
(There are some possible foot-gun scenarios if the option were changed
subsequent to table creation, so we'd either need to decide how to
deal with those, or decide not to allow it.)
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Guillaume Smet | 2009-08-23 12:49:05 | Re: Performance regression between 8.3 and 8.4 on heavy text indexing |
Previous Message | Alvaro Herrera | 2009-08-21 20:12:25 | Re: number of rows estimation for bit-AND operation |