Thread: UNLOGGED tables in psql \d
psql \d(+) doesn't show any information about UNLOGGED and TEMP attributes for the table. So, we cannot know the table is unlogged or not unless we directly select from pg_class.relpersistence. Is this a TODO item? The same issue is in TEMP tables, but we can determine them by their schema; they are always created in pg_temp_N schema. -- Itagaki Takahiro
2011/2/22 Itagaki Takahiro <itagaki.takahiro@gmail.com>: > psql \d(+) doesn't show any information about UNLOGGED and TEMP attributes > for the table. So, we cannot know the table is unlogged or not unless > we directly select from pg_class.relpersistence. Is this a TODO item? > > The same issue is in TEMP tables, but we can determine them by their > schema; they are always created in pg_temp_N schema. I believe it is in the "title" of the table presented by \d (Table, Unlogged table, Temp table) -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support
On Tue, Feb 22, 2011 at 18:11, Cédric Villemain <cedric.villemain.debian@gmail.com> wrote: > 2011/2/22 Itagaki Takahiro <itagaki.takahiro@gmail.com>: >> psql \d(+) doesn't show any information about UNLOGGED and TEMP attributes >> for the table. So, we cannot know the table is unlogged or not unless >> we directly select from pg_class.relpersistence. Is this a TODO item? > > I believe it is in the "title" of the table presented by \d (Table, > Unlogged table, Temp table) Ah, I see. Thank you. They are shown as "Unlogged Table" and "Unlogged Index". - We don't have "Temp" for temp tables. Should we have? - The head characters of the second words would be small letters. We describe other objects as "Composite type", "Foreigntable", or so. -- Itagaki Takahiro
2011/2/22 Itagaki Takahiro <itagaki.takahiro@gmail.com>: > On Tue, Feb 22, 2011 at 18:11, Cédric Villemain > <cedric.villemain.debian@gmail.com> wrote: >> 2011/2/22 Itagaki Takahiro <itagaki.takahiro@gmail.com>: >>> psql \d(+) doesn't show any information about UNLOGGED and TEMP attributes >>> for the table. So, we cannot know the table is unlogged or not unless >>> we directly select from pg_class.relpersistence. Is this a TODO item? >> >> I believe it is in the "title" of the table presented by \d (Table, >> Unlogged table, Temp table) > > Ah, I see. Thank you. They are shown as "Unlogged Table" and > "Unlogged Index". > > - We don't have "Temp" for temp tables. Should we have? Hum, First, I would say yes to be more consistent with the unlogged case, but 2nd we must refrain from outputting too much information where it is not relevant. The fact that you didn''t saw it might be enough to reconsider the way we display the unlogged state (and temp state) of a relation. Maybe some a "Durability: normal, temp, unlogged" line at bottom of the \d output ? > - The head characters of the second words would be small letters. > We describe other objects as "Composite type", "Foreign table", or so. > > -- > Itagaki Takahiro > -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support
On Tue, Feb 22, 2011 at 8:03 AM, Cédric Villemain <cedric.villemain.debian@gmail.com> wrote: > The fact that you didn''t saw it might be enough to reconsider the way > we display the unlogged state (and temp state) of a relation. > > Maybe some a "Durability: normal, temp, unlogged" line at bottom of > the \d output ? The term we use internally is "persistence", but I'm not really sure it's worth making the \d output longer. In fact I'd much rather find some way of going the other direction. Note also that the temp-ness of a table can already be inferred from the schema. Another thought is that we might eventually have global temporary tables, where the schema is globally visible (like a permanent or unlogged table) but each backend sees only its own contents. So whatever we come up with here should generalize to that case as well. Still another point is that "temp" can apply to any object type, but "unlogged" can only apply to tables, indexes, and sequences. (We don't currently implement it for sequences, though.) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company