Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

From: Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, David Steele <david(at)pgmasters(dot)net>
Subject: Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)
Date: 2016-08-08 08:47:32
Message-ID: 44fd10a5-2d16-86a4-5192-b85a6a16790c@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

05.08.2016 19:41, Robert Haas:
>
> 2. This inserts additional code in a bunch of really low-level places
> like heap_hot_search_buffer, heap_update, heap_delete, etc. I think
> what you've basically done here is create a new, in-memory heap AM and
> then, because we don't have an API for adding new storage managers,
> you've bolted it onto the existing heapam layer. That's certainly a
> reasonable approach for creating a PoC, but I think we actually need a
> real API here. Otherwise, when the next person comes along and wants
> to add a third heap implementation, they've got to modify all of these
> same places again. I don't think this code is reasonably maintainable
> in this form.

As I can see, you recommend to clean up the API of storage
management code. I strongly agree that it's high time to do it.

So, I started the discussion about refactoring and improving API
of heapam and heap relations.
You can find it on commitfest:
https://commitfest.postgresql.org/10/700/

I'll be glad to see your thoughts on the thread.

--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2016-08-08 09:11:54 Re: handling unconvertible error messages
Previous Message Yugo Nagata 2016-08-08 08:40:00 per-statement-level INSTEAD OF triggers