From: Aleksander Alekseev <a.alekseev@postgrespro.ru>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Pavel Stehule <pavel.stehule@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: David Steele <david@pgmasters.net>
Subject: Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)
Date: Mon, 1 Aug 2016 12:45:31 +0300
Message-ID: <20160801124531.66cde374@fujitsu> (raw)
In-Reply-To: <5cdc3fde-d6a5-f0d2-b930-485bdcaecde5@2ndquadrant.com>
References: <20160729141552.4062e19b@fujitsu>
<39b0f423-a4df-3564-3b4a-b1de6f9eea80@2ndquadrant.com>
<CAFj8pRAv+vPxzTQMviCsYqQrfpYei5bTvX80zRUp1Q3xAbTWyg@mail.gmail.com>
<1184.1469890030@sss.pgh.pa.us>
<5cdc3fde-d6a5-f0d2-b930-485bdcaecde5@2ndquadrant.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Hello.
Thanks everyone for great comments!
> Well, jokes aside, that's a pretty lousy excuse for not writing any
> docs
I think maybe I put it in a wrong way. There are currently a lot of
comments in a code, more then enough to understand how this feature
works. What I meant is that this is not a final version of a patch and
a few paragraphs are yet to be written. At least it's how I see it. If
you believe that some parts of the code are currently hard to understand
and some comments could be improved, please name it and I will be happy
to fix it.
> IMHO if this patch gets in, we should use it as the only temp table
> implementation (Or can you think of cases where keeping rows in
> pg_class has advantages?). That'd also eliminate the need for FAST
> keyword in the CREATE TABLE command.
> Probably has zero value to have slow and fast temp tables (from
> catalogue cost perspective). So the FAST implementation should be used
> everywhere.
If there are no objections I see no reason no to do it in a next
version of a patch.
> I'm getting failures in the regression suite
I've run regression suite like 10 times in a row in different
environments with different build flags but didn't manage to reproduce
it. Also our DBAs are testing this feature for weeks now on real-world
applications and they didn't report anything like this. Could you
please describe how to reproduce this issue?
> This should to work on slaves - it is one of ToDo
Glad you noticed! In fact I'm currently researching a possibility of
using the same approach for creating writable temporary tables on
replicas.
> The key reason why I don't think that's negotiable is that if there
> aren't (apparently) catalog entries corresponding to the temp tables,
> that will almost certainly break many things in the backend and
> third-party extensions, not only user code patterns like this one.
> In short, I think that the way to make something like this work is to
> figure out how to have "virtual" catalog rows describing a temp table.
I'm afraid once again I put it in a wrong way. What I meant by
"Information about these tables is stored not in a catalog but in
backend's memory" is in fact that _records_ of pg_class, pg_type and
other catalog relations are stored in-memory. Naturally this records
are visible to the user (otherwise \d or \d+ would not work) and you
can do queries like ` select * from pg_class where relname = 'tt1' `.
In other words part of the catalog is indeed "virtual".
> I didn't see support for memory store for column's statistics. Some
> separate questions is about production statistics -
> pg_stat_user_table, ..
> That seems to work (both analyze and pg_stat_user_tables). Not sure
> where it's in the code, and I'm not willing to reverse engineer it.
Right, `ANALYZE temp_table;` and everything else works. Besides
pg_class, pg_type, pg_attribute and other relations pg_statistic
records for temp tables are stored in-memory as well. IIRC a lot of
pg_stat* relations are in fact views and thus don't require any special
support. If you see that some statistics are broken please don't
hesitate to report it and I will fix it.
Hope I answered all questions so far. I look forward to receive more
comments and questions regarding this patch!
--
Best regards,
Aleksander Alekseev
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: a.alekseev@postgrespro.ru, tomas.vondra@2ndquadrant.com, tgl@sss.pgh.pa.us, pavel.stehule@gmail.com, david@pgmasters.net
Subject: Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)
In-Reply-To: <20160801124531.66cde374@fujitsu>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox