As far as I know we are trying to kill two birds with one stone:
1. Reduce overhead of accessing temporary tables
2. Make it possible to create temporary tables on replica.
Replicas with hot-standby are widely used for running read-only OLAP queries.
But such queries usually stores intermediate r
2016-03-01 20:17 GMT+01:00 Jim Nasby :
> On 3/1/16 10:05 AM, Atri Sharma wrote:
>
>> Fair point, that means inventing a whole new OID generation structure..
>>
>
> Generation is just the tip of the iceberg. You still need the equivalent
> to foreign keys (ie: pg_depend). While you would never have
On 3/1/16 10:05 AM, Atri Sharma wrote:
Fair point, that means inventing a whole new OID generation structure..
Generation is just the tip of the iceberg. You still need the equivalent
to foreign keys (ie: pg_depend). While you would never have a permanent
object depend on a temp object, the r
2016-03-01 17:00 GMT+01:00 Robert Haas :
> On Tue, Mar 1, 2016 at 10:52 AM, Tom Lane wrote:
> > Aleksander Alekseev writes:
> >> There are applications that create and delete a lot of temporary
> >> tables. Currently PostgreSQL doesn't handle such a use case well.
> >
> > True.
> >
> >> Fast tem
On Tue, Mar 1, 2016 at 10:52 AM, Tom Lane wrote:
> Aleksander Alekseev writes:
>> There are applications that create and delete a lot of temporary
>> tables. Currently PostgreSQL doesn't handle such a use case well.
>
> True.
>
>> Fast temporary tables work almost as usual temporary tables but th
On Tue, Mar 1, 2016 at 9:30 PM, Robert Haas wrote:
> On Tue, Mar 1, 2016 at 10:52 AM, Tom Lane wrote:
> > Aleksander Alekseev writes:
> >> There are applications that create and delete a lot of temporary
> >> tables. Currently PostgreSQL doesn't handle such a use case well.
>
>
> Yeah, I have a
>
>
>
> I think you have no concept how invasive that would be. Tables not
> represented in the catalogs would be a disaster, because *every single
> part of the backend* would have to be modified to deal with them as
> a distinct code path --- parser, planner, executor, loads and loads
> of utili
Aleksander Alekseev writes:
> There are applications that create and delete a lot of temporary
> tables. Currently PostgreSQL doesn't handle such a use case well.
True.
> Fast temporary tables work almost as usual temporary tables but they
> are not present in the catalog. Information about tabl
On Tue, Mar 1, 2016 at 8:55 PM, Aleksander Alekseev <
a.aleks...@postgrespro.ru> wrote:
> Hello
>
> There are applications that create and delete a lot of temporary
> tables. Currently PostgreSQL doesn't handle such a use case well.
> Consider the following benchmark/example.
>
>
FWIW, I and Pavel
Hello
There are applications that create and delete a lot of temporary
tables. Currently PostgreSQL doesn't handle such a use case well.
Consider the following benchmark/example.
postgresql.conf:
```
autovacuum = on
log_min_messages = debug2
```
temp-table.pgbench:
```
create temporary table t
10 matches
Mail list logo
