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 (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers