From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
---|---|
To: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables) |
Date: | 2016-08-24 00:12:36 |
Message-ID: | 58b5c129-5df4-0bf6-9468-ae119b6428d0@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 08/24/2016 12:38 AM, Claudio Freire wrote:
> On Tue, Aug 23, 2016 at 7:25 PM, Tomas Vondra
> <tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
>>>> Could someone please explain how the unlogged tables are supposed to fix
>>>> the
>>>> catalog bloat problem, as stated in the initial patch submission? We'd
>>>> still
>>>> need to insert/delete the catalog rows when creating/dropping the
>>>> temporary
>>>> tables, causing the bloat. Or is there something I'm missing?
>>>
>>>
>>> Wouldn't more aggressive vacuuming of catalog tables fix the bloat?
>>>
>>> Perhaps reserving a worker or N to run only on catalog schemas?
>>>
>>> That'd be far simpler.
>>
>>
>> Maybe, although IIRC the issues with catalog bloat were due to a combination
>> of long queries and many temporary tables being created/dropped. In that
>> case simply ramping up autovacuum (or even having a dedicated workers for
>> catalogs) would not realy help due to the xmin horizon being blocked by the
>> long-running queries.
>>
>> Maybe it's entirely crazy idea due to the wine I drank at the dinner, but
>> couldn't we vacuum the temporary table records differently? For example,
>> couldn't we just consider them removable as soon as the backend that owns
>> them disappears?
>
> Or perhaps go all the way and generalize that to rows that never
> become visible outside their parent transaction.
>
> As in, delete of rows created by the deleting transaction could clean
> up, carefully to avoid voiding indexes and all that, but more
> aggressively than regular deletes.
>
Maybe, but I wouldn't be surprised if such generalization would be an
order of magnitude more complicated - and even the vacuuming changes I
mentioned are undoubtedly a fair amount of work.
Sadly, I don't see how this might fix the other issues mentioned in this
thread (e.g. impossibility to create temp tables on standbys),
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2016-08-24 00:55:38 | Re: Patch: initdb: "'" for QUOTE_PATH (non-windows) |
Previous Message | Mark Kirkwood | 2016-08-24 00:09:48 | Re: Write Ahead Logging for Hash Indexes |