Re: System views for versions reporting

Dmitry Dolgov <9erthali...@gmail.com> writes: > Thanks for checking this out. Here is the updated version with applied > changes. The tests were failing due to injection_points library > apparently linking something twice, triggering a duplication error I > didn't expect. Since apparently it can ha

Re: System views for versions reporting

> On Sun, Mar 23, 2025 at 06:21:33PM GMT, Tom Lane wrote: > > FWIW, I think the 0004 patch is about to be mostly obsoleted by > Andrei's proposal at [1]. To the extent that it's not obsoleted, > I question whether it's something we want at all, given the ground > rule that unprivileged users are n

Re: System views for versions reporting

> On Thu, Jan 02, 2025 at 10:36:48AM GMT, jian he wrote: > hi. > https://cirrus-ci.com/github/postgresql-cfbot/postgresql/cf%2F5318 > shows lots of failures, but it doesn't seem to tell you about doc build > failure. Thanks for checking this out. Here is the updated version with applied changes.

Re: Temporary Views Cleanup Issue

"=?UTF-8?B?6LW15a6H6bmPKOWuh+W9rSk=?=" writes: > We encountered a scenario where orphaned temporary views are preventing DDL > operations on a table, such as "ALTER TABLE xxx ALTER COLUMN xxx TYPE xxx." > The > corresponding error message is "ERROR: canno

Re: Temporary Views Cleanup Issue

Hello, Thank you for your response. We encountered a scenario where orphaned temporary views are preventing DDL operations on a table, such as "ALTER TABLE xxx ALTER COLUMN xxx TYPE xxx." The corresponding error message is "ERROR: cannot alter type of a column used by a view or

Re: Temporary Views Cleanup Issue

exits abnormally, the > temporary table is cleaned up. I think this is intentional. A temp table may consume enough disk space that it's worth hacking up autovacuum to remove the space. The same cannot be said of other kinds of objects. (If we had temp materialized views, they might be wort

Temporary Views Cleanup Issue

ely. This cleanup can be handled in do_autovacuum(), but the code currently only covers regular tables (relkind=r). Temporary relations may also include temporary views (relkind=v), temporary sequences (relkind=S), and temporary partitioned tables (relkind=p). I have written a test script to repro

Re: System views for versions reporting

On 2025-01-02 10:36:48 +0800, jian he wrote: > https://cirrus-ci.com/github/postgresql-cfbot/postgresql/cf%2F5318 > shows lots of failures, but it doesn't seem to tell you about doc build > failure. It does: https://cirrus-ci.com/task/6472750665039872?logs=docs_build#L0 [15:26:26.443] time make -

Re: System views for versions reporting

hi. https://cirrus-ci.com/github/postgresql-cfbot/postgresql/cf%2F5318 shows lots of failures, but it doesn't seem to tell you about doc build failure. + + pg_system_versions + + + pg_system_versions + + should change to + otherwise cannot build doc. + + pg_system_versions Colum

Re: Add pg_ownerships and pg_privileges system views

Hi hackers, As noted in previous feedback, relying on pg_shdepend leads to a less-than-ideal behavior: no privileges are displayed for an object until at least one privilege is granted to a role other than the owner, as explained by Alvaro: On Sun, Oct 20, 2024, at 12:14, Alvaro Herrera wrote: >

Re: Add pg_ownerships and pg_privileges system views

On Mon, Oct 21, 2024, at 11:42, Alvaro Herrera wrote: > ... actually, the "AND pg_shdepend.dbid = ( SELECT pg_database_1.oid > ...)" part of this is useless, because you already had that in the ON > condition of the original join to pg_database. So, apologies for the > noise there. TBH I don't se

Re: Add pg_ownerships and pg_privileges system views

On 2024-Oct-20, Alvaro Herrera wrote: > SELECT > pg_shdepend.classid, > pg_shdepend.objid, > pg_shdepend.objsubid, > identify.*, > aclexplode.* > FROM pg_catalog.pg_shdepend > JOIN pg_catalog.pg_database ON pg_data

Re: Add pg_ownerships and pg_privileges system views

On Sun, Oct 20, 2024, at 23:03, Joel Jacobson wrote: > On Sun, Oct 20, 2024, at 16:52, Joel Jacobson wrote: >> On Sun, Oct 20, 2024, at 12:14, Alvaro Herrera wrote: >>> I think the function calls should be in the FROM clause, and restrict the >>> pg_shdepend rows to only the ones in the current dat

Re: Add pg_ownerships and pg_privileges system views

On Sun, Oct 20, 2024, at 16:52, Joel Jacobson wrote: > On Sun, Oct 20, 2024, at 12:14, Alvaro Herrera wrote: >> I think the function calls should be in the FROM clause, and restrict the >> pg_shdepend rows to only the ones in the current database: > > Cool. I assume pg_ownerships should be changed

Re: Add pg_ownerships and pg_privileges system views

On Sun, Oct 20, 2024, at 12:14, Alvaro Herrera wrote: > I think the function calls should be in the FROM clause, and restrict the > pg_shdepend rows to only the ones in the current database: Cool. I assume pg_ownerships should be changed in the same way? New patch attached. > Now, depending on pg

Re: Add pg_ownerships and pg_privileges system views

Hello, On 2024-Oct-20, Joel Jacobson wrote: > Here is an attempt to revive this patch from 2021-2022, that has been ready > now > for a while, thanks to pg_get_acl() function that was committed in > 4564f1c and d898665. Nice. I think the function calls should be in the FROM clause, and restric

Add pg_ownerships and pg_privileges system views

rg/50/5033/ --- Add pg_ownerships and pg_privileges system views. These new views provide a more accessible and user-friendly way to retrieve information about object ownerships and privileges. The view pg_ownerships provides access to information about object ownerships. The view pg_privi

Re: System views for versions reporting

> On Mon, Oct 07, 2024 at 11:26:41AM GMT, Dmitry Dolgov wrote: > > On Sun, Oct 06, 2024 at 12:01:29PM GMT, Joe Conway wrote: > > I'm not sure why ICU is "Compile Time" rather than "Run Time" when it is not > > statically linked. > > It reports U_UNICODE_VERSION at compile time. It's not necessarily

Re: System views for versions reporting

Joe Conway writes: > On 10/16/24 08:47, Peter Eisentraut wrote: >> That way, you can get this information without having to start a server >> instance. (Maybe you can't start a server instance because it just >> crashed because of some library version issue ...) > While it is also useful to be a

Re: System views for versions reporting

On 10/16/24 08:47, Peter Eisentraut wrote: On 06.10.24 17:36, Dmitry Dolgov wrote: Based on the feedback in [1], here is my attempt at implementing system views for versions reporting. It adds pg_system_versions for showing things like core version, compiler, LLVM, etc, and pg_system_libraries

Re: System views for versions reporting

On 06.10.24 17:36, Dmitry Dolgov wrote: Based on the feedback in [1], here is my attempt at implementing system views for versions reporting. It adds pg_system_versions for showing things like core version, compiler, LLVM, etc, and pg_system_libraries for showing linked shared objects. Is a

Re: System views for versions reporting

> On Sun, Oct 06, 2024 at 12:01:29PM GMT, Joe Conway wrote: > On 10/6/24 11:36, Dmitry Dolgov wrote: > > Hi, > > > > Based on the feedback in [1], here is my attempt at implementing system > > views for versions reporting. It adds pg_system_versions for showin

Re: System views for versions reporting

Joe Conway writes: > I think it would be nice to include a sha256 hash (or something similar) > of the libraries as well, so that they can be checked against known good > values. That seems well outside the charter of this patch. Also, how would we even get that information? A typical applica

Re: System views for versions reporting

On 10/6/24 11:36, Dmitry Dolgov wrote: Hi, Based on the feedback in [1], here is my attempt at implementing system views for versions reporting. It adds pg_system_versions for showing things like core version, compiler, LLVM, etc, and pg_system_libraries for showing linked shared objects. I

System views for versions reporting

Hi, Based on the feedback in [1], here is my attempt at implementing system views for versions reporting. It adds pg_system_versions for showing things like core version, compiler, LLVM, etc, and pg_system_libraries for showing linked shared objects. I think everyone has ageed that the first was

Re: Restrict EXPLAIN (ANALYZE) for RLS and security_barrier views

On Mon, 2024-05-06 at 16:46 +0200, Laurenz Albe wrote: > Currently, it is pretty easy to subvert the restrictions imposed > by row-level security and security_barrier views.  All you have to > to is use EXPLAIN (ANALYZE) and see how many rows were filtered > out by the RLS policy

Re: Restrict EXPLAIN (ANALYZE) for RLS and security_barrier views

On Tue, 2024-07-16 at 18:36 +0100, Dean Rasheed wrote: > On Mon, 6 May 2024 at 15:46, Laurenz Albe wrote: > > > > Currently, it is pretty easy to subvert the restrictions imposed > > by row-level security and security_barrier views. All you have to > > to is use EX

Re: Restrict EXPLAIN (ANALYZE) for RLS and security_barrier views

On Mon, 6 May 2024 at 15:46, Laurenz Albe wrote: > > Currently, it is pretty easy to subvert the restrictions imposed > by row-level security and security_barrier views. All you have to > to is use EXPLAIN (ANALYZE) and see how many rows were filtered > out by the RLS pol

Re: Restrict EXPLAIN (ANALYZE) for RLS and security_barrier views

ity or security barrier views. This is not considered a security bug, but we ought to do better. Restricting the use of EXPLAIN (ANALYZE) to superusers in such cases would be too much, and superusers bypass row-level security, so that would leave no way to debug such statements. Consequently, re

Restrict EXPLAIN (ANALYZE) for RLS and security_barrier views

Currently, it is pretty easy to subvert the restrictions imposed by row-level security and security_barrier views. All you have to to is use EXPLAIN (ANALYZE) and see how many rows were filtered out by the RLS policy or the view condition. This is not considered a security bug (I asked), but I

Materialized views and check constraints

Hi, Is there any way to add check constraints to a materialized view, or plans to add this feature in the future? Attempting to use "ALTER TABLE tablename ADD CHECK(...)" or "ALTER MATERIALIZED VIEW" result in error: ERROR: "tablename" is not a table or foreign table Check constraints are used

Re: PSQL Should \sv & \ev work with materialized views?

hat yet. > > > > Not just those — also anything that depends on the matview, such as views > and other matviews. Right. But you'd run into the same issue for a regular view if you use \ev and add DROP VIEW myview CASCADE which may be necessary if you want to change columns n

Re: PSQL Should \sv & \ev work with materialized views?

On Thu, 28 Mar 2024 at 20:38, Erik Wienhold wrote: > Of course the problem with using DROP and CREATE is that indexes and > privileges (anything else?) must also be restored. I haven't bothered > with that yet. > Not just those — also anything that depends on the matview,

Re: PSQL Should \sv & \ev work with materialized views?

l > lacks commands to show their definitions. > > But I think that it should be separate commands \sm and \em because we > already have commands \dm and \dv that distinguish between matviews and > views. Separate commands are not necessary because \ev and \sv already have a (disabled

Re: PSQL Should \sv & \ev work with materialized views?

their definitions. But I think that it should be separate commands \sm and \em because we already have commands \dm and \dv that distinguish between matviews and views. > This should not be that difficult. Just looking for feedback. > Admittedly \e is questionable, because you cannot really apply

Re: Supporting MERGE on updatable views

On Thu, 29 Feb 2024 at 09:50, Alvaro Herrera wrote: > > By all means let's get the feature out there. It's not a frequently > requested thing but it does seem to come up. > Pushed. Thanks for reviewing. Regards, Dean

Re: Supporting MERGE on updatable views

On 2024-Feb-29, Dean Rasheed wrote: > Going over this again, I spotted a bug -- the UPDATE path in > ExecMergeMatched() wasn't calling ExecUpdateEpilogue() for > trigger-updatable views, because it wasn't setting updateCxt.updated > to true. (This matters if you have an au

Re: Supporting MERGE on updatable views

On 2024-Jan-29, Dean Rasheed wrote: > Yeah, for all practical purposes, that check in CheckValidResultRel() > has been dead code since d751ba5235, but I think it's still worth > doing, and if we're going to do it, we should do it properly. I don't > like using elog() in some cases and ereport() in

Re: Supporting MERGE on updatable views

Thanks for working on this. The patch looks well finished. I didn't try to run it, though. I gave it a read and found nothing to complain about, just these two pretty minor comments: On 2024-Jan-26, Dean Rasheed wrote: > diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execM

Re: Supporting MERGE on updatable views

x27;t want to include MERGE in that sentence, because MERGE isn't > > supported on views or tables with rules, but I guess we could add > > another sentence after that one, to make that clear. > > > > Here's an updated patch doing that, plus another couple of m

Re: [PGDOCS] Inconsistent linkends to "monitoring" views.

On Wed, Nov 8, 2023 at 2:02 PM John Naylor wrote: > My 2 cents: Comment typos are visible to readers, so more annoying > when seen in isolation, and less likely to have surroundings that > could change in back branches. Consistency would preferred all else > being equal, but then again nothing is

Re: [PGDOCS] Inconsistent linkends to "monitoring" views.

On Tue, Oct 3, 2023 at 4:40 PM Peter Smith wrote: > > On Tue, Oct 3, 2023 at 6:30 PM Michael Paquier wrote: > > > > On Tue, Oct 03, 2023 at 01:11:15PM +1100, Peter Smith wrote: > > > I noticed one or two "monitoring" links and linkends that are slightly > > > inconsistent from all the others. > >

Re: Supporting MERGE on updatable views

se > relations has an INSTEAD rule that causes the > INSERT or UPDATE command > to be rewritten, then > all check options will be ignored in the rewritten query, including any > checks from automatically updatable views defined on top of the relation >

Re: Supporting MERGE on updatable views

hen all check options will be ignored in the rewritten query, including any checks from automatically updatable views defined on top of the relation with the INSTEAD rule. in src/backend/executor/nodeModifyTable.c line 3800: ExecModifyTable ` datum = ExecGetJunkAttribute(s

Re: [PGDOCS] Inconsistent linkends to "monitoring" views.

On Tue, Oct 3, 2023 at 6:30 PM Michael Paquier wrote: > > On Tue, Oct 03, 2023 at 01:11:15PM +1100, Peter Smith wrote: > > I noticed one or two "monitoring" links and linkends that are slightly > > inconsistent from all the others. > > - > + > > Is that really worth bothering for the interna

Re: [PGDOCS] Inconsistent linkends to "monitoring" views.

On Tue, Oct 03, 2023 at 01:11:15PM +1100, Peter Smith wrote: > I noticed one or two "monitoring" links and linkends that are slightly > inconsistent from all the others. - + Is that really worth bothering for the internal link references? This can create extra backpatching conflicts. -- Mi

[PGDOCS] Inconsistent linkends to "monitoring" views.

I noticed one or two "monitoring" links and linkends that are slightly inconsistent from all the others. ~~~ >From "Dynamic Statistics Views" pg_stat_activity, linkend="monitoring-pg-stat-activity-view" ==> ok pg_stat_replication, linkend="mo

Re: Skip Orderby Execution for Materialized Views

On Sun, Oct 1, 2023 at 8:57 AM Zhang Mingli wrote: > And if it’s true, shall we skip the order by clause for Materialized > View when executing create/refresh statement? > We tend to do precisely what the user writes into their query. If they don't want an order by they can remove it. I don't

Re: Skip Orderby Execution for Materialized Views

HI, > On Oct 1, 2023, at 22:54, Tom Lane wrote: > > For one example, > you can't just remove the sort clause if the query uses DISTINCT ON Hi, Tom, got it, thanks, Zhang Mingli HashData https://www.hashdata.xyz

Re: Skip Orderby Execution for Materialized Views

Zhang Mingli writes: > When create  or refresh a Materialized View, if the view’s query has order > by, we may sort and insert the sorted data into view. Indeed. > And if it’s true, shall we skip the order by clause for Materialized View   > when executing create/refresh statement? No. The in

Skip Orderby Execution for Materialized Views

Hi, all When create  or refresh a Materialized View, if the view’s query has order by, we may sort and insert the sorted data into view. Create Materialized View mv1 as select c1, c2 from t1 order by c2; Refresh Materialized View mv1; And it appears that we could get ordered da

Re: Views no longer in rangeTabls?

On 6/14/23 12:51, Amit Langote wrote: Ah, did think it might be moderation.  Thanks for the confirmation, Michael. It’s out now: https://www.postgresql.org/message-id/E1q9Gms-001h5g-8Q%40gemulon.postgresql.org

Re: Views no longer in rangeTabls?

On Wed, Jun 14, 2023 at 15:49 Amit Langote wrote: > On Wed, Jun 14, 2023 at 15:44 Michael Paquier wrote: > >> On Wed, Jun 14, 2023 at 02:34:56PM +0900, Amit Langote wrote: >> > This being my first commit, I intently looked to check if everything’s >> set >> > up correctly. While it seemed to hav

Re: Views no longer in rangeTabls?

On Wed, Jun 14, 2023 at 15:44 Michael Paquier wrote: > On Wed, Jun 14, 2023 at 02:34:56PM +0900, Amit Langote wrote: > > This being my first commit, I intently looked to check if everything’s > set > > up correctly. While it seemed to have hit gitweb and GitHub, it didn’t > > pgsql-committers for

Re: Views no longer in rangeTabls?

On Wed, Jun 14, 2023 at 02:34:56PM +0900, Amit Langote wrote: > This being my first commit, I intently looked to check if everything’s set > up correctly. While it seemed to have hit gitweb and GitHub, it didn’t > pgsql-committers for some reason. It seems to me that the email of pgsql-committers

Re: Views no longer in rangeTabls?

On Wed, Jun 14, 2023 at 12:08 Amit Langote wrote: > On Tue, Jun 13, 2023 at 9:40 PM David Steele wrote: > > On 6/13/23 11:38, Amit Langote wrote: > > > On Tue, Jun 13, 2023 at 6:33 PM Alvaro Herrera < > alvhe...@alvh.no-ip.org> wrote: > > >> Note that you changed one comment from "permission che

Re: Views no longer in rangeTabls?

On Tue, Jun 13, 2023 at 9:40 PM David Steele wrote: > On 6/13/23 11:38, Amit Langote wrote: > > On Tue, Jun 13, 2023 at 6:33 PM Alvaro Herrera > > wrote: > >> Note that you changed one comment from "permission checks" to > >> "permission hecks". > > > > Oops, thanks for pointing that out. > > >

Re: Views no longer in rangeTabls?

On 6/13/23 11:38, Amit Langote wrote: On Tue, Jun 13, 2023 at 6:33 PM Alvaro Herrera wrote: Note that you changed one comment from "permission checks" to "permission hecks". Oops, thanks for pointing that out. Fixed in the attached. I have done another (more careful) review of the comments

Re: Views no longer in rangeTabls?

On Tue, Jun 13, 2023 at 6:33 PM Alvaro Herrera wrote: > Note that you changed one comment from "permission checks" to > "permission hecks". Oops, thanks for pointing that out. Fixed in the attached. -- Thanks, Amit Langote EDB: http://www.enterprisedb.com v3-0001-Retain-relkind-too-in-RTE_SU

Re: Views no longer in rangeTabls?

Note that you changed one comment from "permission checks" to "permission hecks". -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "No nos atrevemos a muchas cosas porque son difíciles, pero son difíciles porque no nos atrevemos a hacerlas" (Séneca)

Re: Views no longer in rangeTabls?

On 6/13/23 10:27, Amit Langote wrote: On Tue, Jun 13, 2023 at 4:44 PM David Steele wrote: I decided to go with the following because I think it is easier to read: /* We only care about tables/views and can ignore subqueries, etc. */ if (!(rte->rtekind == RTE_RELATION || (rte->r

Re: Views no longer in rangeTabls?

st for a detail as tiny as this. > > > > OK, so how about the attached? > > The patch looks good to me. I also tested it against pgAudit and > everything worked. Thanks for the review. > I decided to go with the following because I think it > is easier to read: >

Re: Views no longer in rangeTabls?

k it is easier to read: /* We only care about tables/views and can ignore subqueries, etc. */ if (!(rte->rtekind == RTE_RELATION || (rte->rtekind == RTE_SUBQUERY && rte->relkind == RELKIND_VIEW))) continue; I considered adding Assert(relkind == RELKIND_VIEW) in all

Re: Views no longer in rangeTabls?

795b Mon Sep 17 00:00:00 2001 From: Amit Langote Date: Tue, 13 Jun 2023 12:52:47 +0900 Subject: [PATCH v1] Retain relkind too in RTE_SUBQUERY entries for views. 47bb9db75 modified the ApplyRetrieveRule()'s conversion of a view's original RTE_RELATION entry into an RTE_SUBQUERY one to retain

Re: Views no longer in rangeTabls?

Julien Rouhaud writes: > On Sat, Jun 10, 2023 at 08:56:47AM -0400, Tom Lane wrote: >> - rte->relkind = 0; > and also handle that field in (read|out)funcs.c Oh, right. Ugh, that means a catversion bump. It's not like we've never done that during beta, but it's kind of an annoying cost for a d

Re: Views no longer in rangeTabls?

On Sat, Jun 10, 2023 at 08:56:47AM -0400, Tom Lane wrote: > > Well, if we're gonna do it we should do it for v16, rather than > change the data structure twice. It wouldn't be hard exactly: > > /* > * Clear fields that should not be set in a subquery RTE. Note that we > * leave the

Re: Views no longer in rangeTabls?

David Steele writes: > On 6/10/23 09:57, Amit Langote wrote: >> I too have been thinking that setting relkind might be a good idea, even >> if only as a crosscheck that only view relations can look like that in >> the range table. > +1. Even better if we can do it for PG16. Well, if we're gonn

Re: Views no longer in rangeTabls?

On 6/10/23 09:57, Amit Langote wrote: On Sat, Jun 10, 2023 at 15:51 David Steele > wrote: On 6/9/23 19:14, Tom Lane wrote: > > If you see "rte->rtekind == RTE_SUBQUERY && OidIsValid(rte->relid)", > it's dead certain that relid refers to a view, so yo

Re: Views no longer in rangeTabls?

On Sat, Jun 10, 2023 at 15:51 David Steele wrote: > On 6/9/23 19:14, Tom Lane wrote: > > David Steele writes: > >> Thank you, this was very helpful. I am able to get the expected result > >> now with: > > > >> /* We only care about tables/views and can

Re: Views no longer in rangeTabls?

On 6/9/23 19:14, Tom Lane wrote: David Steele writes: Thank you, this was very helpful. I am able to get the expected result now with: /* We only care about tables/views and can ignore subqueries, etc. */ if (!(rte->rtekind == RTE_RELATION || (rte->rtekind == RTE_SU

Re: Views no longer in rangeTabls?

David Steele writes: > Thank you, this was very helpful. I am able to get the expected result > now with: > /* We only care about tables/views and can ignore subqueries, etc. */ > if (!(rte->rtekind == RTE_RELATION || > (rte->rtekind == RTE_SUBQUERY &am

Re: Views no longer in rangeTabls?

Hi Amit, On 6/9/23 14:25, Amit Langote wrote: On Fri, Jun 9, 2023 at 17:28 David Steele <mailto:da...@pgmasters.net>> wrote: In prior versions of Postgres, views were listed in rangeTabls when ExecutorCheckPerms_hook() was called but in PG16 the views are no longer in

Re: Views no longer in rangeTabls?

Hi David, On Fri, Jun 9, 2023 at 17:28 David Steele wrote: > Hackers, > > While updating pgAudit for PG16 I found the following (from our > perspective) regression. > > In prior versions of Postgres, views were listed in rangeTabls when > ExecutorCheckPerms_hook() was c

Re: Views no longer in rangeTabls?

On 6/9/23 11:28, David Steele wrote: It seems the thing to do here would be to scan permInfos instead, which works fine except that we also need access to rellockmode, which is only included in rangeTabls. We can add a scan of rangeTabls to get rellockmode when needed and we might be better o

Views no longer in rangeTabls?

Hackers, While updating pgAudit for PG16 I found the following (from our perspective) regression. In prior versions of Postgres, views were listed in rangeTabls when ExecutorCheckPerms_hook() was called but in PG16 the views are no longer in this list. The permissions have been broken out

PSQL Should \sv & \ev work with materialized views?

Personally I would appreciate it if \sv actually showed you the DDL. Oftentimes I will \ev something to review it, with syntax highlighting. Obviously this won't go in until V17, but looking at other tab-completion fixes. This should not be that difficult. Just looking for feedback. Admittedly \

Re: Add n_tup_newpage_upd to pg_stat table views

On Wed, Mar 22, 2023 at 10:38 PM Corey Huinker wrote: > That's probably a good move, especially if we start tallying updates that use > TOAST. Okay, pushed. Thanks -- Peter Geoghegan

Re: Add n_tup_newpage_upd to pg_stat table views

> > > * No more dedicated struct to carry around the type of an update. > > We just use two boolean arguments to the pgstats function instead. The > struct didn't seem to be adding much, and it was distracting to track > the information this way within heap_update(). > That's probably a good move,

Re: Add n_tup_newpage_upd to pg_stat table views

On Wed, Mar 22, 2023 at 05:14:08PM -0700, Peter Geoghegan wrote: > * Small adjustments to the documentation. > > Nearby related items were tweaked slightly to make everything fit > together a bit better. For example, the description of n_tup_hot_upd > is revised to make it obvious that n_tup_hot_u

Re: Add n_tup_newpage_upd to pg_stat table views

On Fri, Mar 17, 2023 at 3:22 PM Peter Geoghegan wrote: > I think that this is pretty close to being committable already. Attached revision has some small tweaks by me. Going to commit this revised version tomorrow morning. Changes: * No more dedicated struct to carry around the type of an updat

Re: Add n_tup_newpage_upd to pg_stat table views

On Fri, Jan 27, 2023 at 3:23 PM Corey Huinker wrote: > This patch adds the n_tup_newpage_upd to all the table stat views. I think that this is pretty close to being committable already. I'll move on that early next week, barring any objections. -- Peter Geoghegan

Re: [DOCS] Stats views and functions not in order?

On 2023-Jan-30, Peter Smith wrote: > On Fri, Jan 27, 2023 at 10:30 PM Peter Eisentraut > wrote: > > We could change the chunking boundary to be sect2 globally. This is > > easily configurable (chunk.section.depth). > > Thinking about it now, maybe this is what we need. As the documentation >

Re: Add n_tup_newpage_upd to pg_stat table views

Hi, On 2023-01-30 13:40:15 -0500, Corey Huinker wrote: > I must be missing something, I only see the check for running out of space, > not the check for exhausting line pointers. I agree dividing them would be > interesting. See PageGetHeapFreeSpace(), particularly the header comment and the MaxH

Re: Add n_tup_newpage_upd to pg_stat table views

On Fri, Jan 27, 2023 at 6:55 PM Andres Freund wrote: > Hi, > > On 2023-01-27 18:23:39 -0500, Corey Huinker wrote: > > This patch adds the n_tup_newpage_upd to all the table stat views. > > > > Just as we currently track HOT updates, it should be beneficial to trac

Re: [DOCS] Stats views and functions not in order?

On 30.01.23 07:12, Peter Smith wrote: Meanwhile, this pagination topic has strayed far away from the original $SUBJECT, so I guess since there is nothing else pending this thread's CF entry [1] can just be marked as "Committed" now? done

Re: [DOCS] Stats views and functions not in order?

On Fri, Jan 27, 2023 at 10:30 PM Peter Eisentraut wrote: > > On 19.01.23 00:45, Peter Smith wrote: > > The original $SUBJECT requirements evolved to also try to make each > > view appear on a separate page after that was suggested by DavidJ [2]. > > I was unable to achieve

Re: Add n_tup_newpage_upd to pg_stat table views

On Fri, Jan 27, 2023 at 6:44 PM Andres Freund wrote: > I don't think that'd make it particularly easy to figure out how often > out-of-space causes non-HOT updates to go out of page, and how often it causes > potential HOT updates to go out of page. If you just have a single index, > it's not too

Re: Add n_tup_newpage_upd to pg_stat table views

Hi, On 2023-01-27 17:59:32 -0800, Peter Geoghegan wrote: > > I think this might cause some trouble for existing monitoring setups after > > an > > upgrade. Suddenly the number of updates will appear way lower than > > before... And if we end up eventually distinguishing between different > > rea

Re: Add n_tup_newpage_upd to pg_stat table views

On Fri, Jan 27, 2023 at 3:55 PM Andres Freund wrote: > I wonder if it's quite detailed enough - we can be forced to do out-of-page > updates because we actually are out of space, or because we reach the max > number of line pointers we allow in a page. HOT pruning can't remove dead line > pointers

Re: Add n_tup_newpage_upd to pg_stat table views

Hi, On 2023-01-27 18:23:39 -0500, Corey Huinker wrote: > This patch adds the n_tup_newpage_upd to all the table stat views. > > Just as we currently track HOT updates, it should be beneficial to track > updates where the new tuple cannot fit on the existing page and must go to >

Add n_tup_newpage_upd to pg_stat table views

This patch adds the n_tup_newpage_upd to all the table stat views. Just as we currently track HOT updates, it should be beneficial to track updates where the new tuple cannot fit on the existing page and must go to a different one. Hopefully this can give users some insight as to whether their

Re: [DOCS] Stats views and functions not in order?

On 19.01.23 00:45, Peter Smith wrote: The original $SUBJECT requirements evolved to also try to make each view appear on a separate page after that was suggested by DavidJ [2]. I was unable to achieve per-page views "without radically changing the document structure." [3], but DavidJ f

Re: [DOCS] Stats views and functions not in order?

On Thu, Jan 19, 2023 at 2:55 AM David G. Johnston wrote: > > On Wed, Jan 18, 2023 at 8:38 AM Tom Lane wrote: >> >> "David G. Johnston" writes: >> > ... I was going for the html effect >> > of having these views chunked into their own pages

Re: [DOCS] Stats views and functions not in order?

On Wed, Jan 18, 2023 at 8:38 AM Tom Lane wrote: > "David G. Johnston" writes: > > ... I was going for the html effect > > of having these views chunked into their own pages, any other changes > being > > non-detrimental. > > But is that a result

Re: [DOCS] Stats views and functions not in order?

"David G. Johnston" writes: > ... I was going for the html effect > of having these views chunked into their own pages, any other changes being > non-detrimental. But is that a result we want? It will for example break any bookmarks that people might have for these documen

Re: [DOCS] Stats views and functions not in order?

ding, please post an updated patch for the same. > > > > Thanks for the reminder. PSA v10. > > So this patch changes some sections describing system views to > refentry's. What is the reason for that? refentry's are basically man > pages; do we want man pages for each

Re: [DOCS] Stats views and functions not in order?

On 11.01.23 07:11, Peter Smith wrote: v9-0003 --> v10-0001 I'm not sure if anything is pending for v9-0003, if there is something pending, please post an updated patch for the same. Thanks for the reminder. PSA v10. So this patch changes some sections describing system views to re

Re: [DOCS] Stats views and functions not in order?

> I'm not sure if anything is pending for v9-0003, if there is something > pending, please post an updated patch for the same. > Thanks for the reminder. PSA v10. -- Kind Regards, Peter Smith. Fujitsu Australia v10-0001-Add-Statistics-Views-section-and-refentry-for-ea.patch Description: Binary data

Re: [DOCS] Stats views and functions not in order?

On Mon, 2 Jan 2023 at 13:47, Peter Eisentraut wrote: > > On 08.12.22 03:30, Peter Smith wrote: > > PSA patches for v9* > > > > v9-0001 - Now the table rows are ordered per PeterE's suggestions [1] > > committed > > > v9-0002 - All the review comments from DavidJ [2] are addressed > > I'm not sure

Re: [DOCS] Stats views and functions not in order?

On 08.12.22 03:30, Peter Smith wrote: PSA patches for v9* v9-0001 - Now the table rows are ordered per PeterE's suggestions [1] committed v9-0002 - All the review comments from DavidJ [2] are addressed I'm not sure about this one. It removes the "see [link] for details" phrases and inste

  1   2   3   4   >