>
>
> The spec does not allow schema changes at all on a a system versioned
> table, except to change the system versioning itself.
>
>
That would greatly simplify things!
On Tue, Mar 15, 2022 at 5:24 PM Greg Stark wrote:
> This looks like an awesome addition.
>
> I have one technical questions...
>
> Is it possible to actually transform the row_number case into a LIMIT
> clause or make the planner support for this case equivalent to it (in
> which case we can repl
>
> I think this can be solved easily in the patch, by having
> ri_BuildQueryKey() compare the parent's fk_attnums to the parent; if
> they are equal then use the parent's constaint_id, otherwise use the
> child constraint. That way, the cache entry is reused in the common
> case where they are id
On Mon, Nov 30, 2020 at 9:48 PM Tom Lane wrote:
> Corey Huinker writes:
> > Given that we're already looking at these checks, I was wondering if this
> > might be the time to consider implementing these checks by directly
> > scanning the constraint index.
&
>
> > It seems to me 1 (RI_PLAN_CHECK_LOOKUPPK) is still alive. (Yeah, I
> > know that doesn't mean the usefulness of the macro but the mechanism
> > the macro suggests, but it is confusing.) On the other hand,
> > RI_PLAN_CHECK_LOOKUPPK_FROM_PK and RI_PLAN_LAST_ON_PK seem to be no
> > longer used.
A Case For Inlining Immediate Referential Integrity Checks
--
The following is an overview of how Postgres currently implemented
referential integrity, the some problems with that architecture, attempted
solutions for those problems, and a su
>
> In addition to that, a following case would be solved with this approach:
> When many processes are referencing many tables defined foreign key
> constraints thoroughly, a huge amount of memory will be consumed
> regardless of whether referenced tables are partitioned or not.
>
> Attached the p
>
>
> In file included from
> /home/japin/Codes/postgresql/Debug/../src/include/postgres.h:47:0,
> from
> /home/japin/Codes/postgresql/Debug/../src/backend/utils/adt/ri_triggers.c:24:
> /home/japin/Codes/postgresql/Debug/../src/backend/utils/adt/ri_triggers.c:
> In function ‘ri_Pri
On Mon, Jan 18, 2021 at 9:45 PM Amit Langote
wrote:
> On Tue, Jan 19, 2021 at 2:47 AM Zhihong Yu wrote:
> >
> > Hi,
> > I was looking at this statement:
> >
> > insert into f select generate_series(1, 200, 2);
> >
> > Since certain generated values (the second half) are not in table p,
> wou
On Wed, Jan 13, 2021 at 1:03 PM Corey Huinker
wrote:
> In addition to that, a following case would be solved with this approach:
>> When many processes are referencing many tables defined foreign key
>> constraints thoroughly, a huge amount of memory will be consumed
>>
>
> I decided not to deviate from pk_ terminology so that the new code
> doesn't look too different from the other code in the file. Although,
> I guess we can at least call the main function
> ri_ReferencedKeyExists() instead of ri_PrimaryKeyExists(), so I've
> changed that.
>
I agree with leavi
>
>
>
> I decided not to deviate from pk_ terminology so that the new code
> doesn't look too different from the other code in the file. Although,
> I guess we can at least call the main function
> ri_ReferencedKeyExists() instead of ri_PrimaryKeyExists(), so I've
> changed that.
>
I think that's
On Sat, Jan 23, 2021 at 12:52 PM Zhihong Yu wrote:
> Hi,
>
> + for (i = 0; i < riinfo->nkeys; i++)
> + {
> + Oid eq_opr = eq_oprs[i];
> + Oid typeid = RIAttType(fk_rel, riinfo->fk_attnums[i]);
> + RI_CompareHashEntry *entry = ri_HashCompareOp(eq_o
On Sun, Jan 24, 2021 at 6:51 AM Amit Langote
wrote:
> On Sun, Jan 24, 2021 at 11:26 AM Corey Huinker
> wrote:
> > On Sat, Jan 23, 2021 at 12:52 PM Zhihong Yu wrote:
> >>
> >> Hi,
>
> Thanks for the review.
>
> >> + for (i = 0; i < riin
On Wed, Feb 10, 2021 at 8:33 AM Pavel Stehule
wrote:
> Hi
>
> Is there some reason why \copy statement (parse_slash_copy parser) doesn't
> support psql variables?
>
> Regards
>
> Pavel
>
I remember wondering about that when I was working on the \if stuff. I dug
into it a bit, but the problem was
On Sun, Dec 5, 2021 at 11:15 AM Daniel Gustafsson wrote:
> > On 5 Dec 2021, at 16:51, Brar Piening wrote:
>
> > The attached patch adds id's to various elements in protocol.sgml to
> > make them more accesssible via the public html documentation interface.
>
> Off the cuff without having checked
>
>
> 0001 adds the \getenv command to psql; now with documentation
> and a simple regression test.
>
+1. Wish I had added this years ago when I had a need for it.
>
> 0002 tweaks pg_regress to export the needed values as environment
> variables, and modifies the test scripts to use those variab
On Sun, Dec 19, 2021 at 5:48 PM Tom Lane wrote:
> Corey Huinker writes:
> > I have a nitpick about the \getenv FOO FOO lines.
> > It's a new function to everyone, and to anyone who hasn't seen the
> > documentation it won't be immediately obvious which one i
On Sun, Dec 19, 2021 at 7:00 PM Tom Lane wrote:
> Corey Huinker writes:
> > Which brings up a tangential question, is there value in having something
> > that brings in one or more env vars as psql vars directly. I'm thinking
> > something like:
>
> >
>
>
>
> I wasn't able to make much inroads into how we might be able to get
> rid of the DETACH-related partition descriptor hacks, the item (3),
> though I made some progress on items (1) and (2).
>
> For (1), the attached 0001 patch adds a new isolation suite
> fk-snapshot.spec to exercise snapsh
>
> Out of curiosity, could you please tell me the concrete situations
> where you wanted to delete one of two identical records?
>
In my case, there is a table with known duplicates, and we would like to
delete all but the one with the lowest ctid, and then add a unique index to
the table which t
>
>
>
> Good catch, thanks. Patch updated.
>
>
>
Applies clean. Passes check-world.
>
>
>
> Perhaps this would be more SQL idiomatic:
>
> FROM permission p
>LEFT JOIN ON KEY role IN p AS r
>LEFT JOIN team_role AS tr ON KEY role TO r
>LEFT JOIN ON KEY team IN tr AS t
>LEFT JOIN user_role AS ur ON KEY role TO r
>LEFT JOIN ON KEY user IN ur AS u
>
>
My second gues
>
>
> First, there is only one FK in permission pointing to role, and we write a
> query leaving out the key columns.
> Then, another different FK in permission pointing to role is later added,
> and our old query is suddenly in trouble.
>
>
We already have that problem with cases where two tables
>
> currently a failed cast throws an error. It would be useful to have a
> way to get a default value instead.
>
I've recently encountered situations where this would have been helpful.
Recently I came across some client code:
CREATE OR REPLACE FUNCTION is_valid_json(str text) RETURNS boolean LA
On Wed, Jan 5, 2022 at 11:07 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 21.11.21 02:51, Paul A Jungwirth wrote:
> > Here are updated patches. They are rebased and clean up some of my
> > TODOs.
>
> This patch set looks very interesting. It's also very big, so it's
> diff
On Thu, Jan 6, 2022 at 12:18 PM Andrew Dunstan wrote:
>
> On 1/4/22 22:17, Corey Huinker wrote:
> >
> > currently a failed cast throws an error. It would be useful to have a
> > way to get a default value instead.
> >
> >
> > I've recent
>
>
> But
> the standard says that dropping system versioning should automatically
> drop all historical records (2 under Part 2: Foundation, 11.30 system versioning clause>). That actually makes sense though: when you
> do DML we automatically update the start/end columns, but we don't
> save co
>
> I'd be
> curious to know where we found the bits for that -- the tuple header
> isn't exactly replete with extra bit space.
>
+1 - and can we somehow shoehorn in a version # into the new format so we
never have to look for spare bits again.
>
> > This is nice. Are there any parallelism capabilities?
>
> Yes. It defaults to number-of-cores processes, but obviously can also be
> specified explicitly. One very nice part about it is that it'd work
> largely the same on windows (which has practically unusable testing
> right now). It prob
>
> I'm sure there's a lot of folks who'd like to see more of the logic we
> have in pg_dump for building objects from the catalog available to more
> tools through libpgcommon- psql being one of the absolute first
> use-cases for exactly that (there's certainly no shortage of people
> who've asked
>
> build support and made the Perl code more portable, so that the cfbot
> doesn't have to be sad.
>
Was this also the reason for doing the output with print statements rather
than using one of the templating libraries? I'm mostly just curious, and
certainly don't want it to get in the way of wor
>
>
> >- @> contains range/element
> >- <@ element/range is contained by
>
I'm not a heavy user or range types, so I can't really judge how useful
> that is in practice, but it seems like a fairly natural extension of the
> existing operators. I mean, if I understand it correctly, the proposed
>
quite sure how to handle terms that have different definitions
in different contexts. Should that be two glossdefs following one
glossterm, or two separate def/term pairs?
Please review and share your thoughts.
From 343d5c18bf23f98341b510595e3e042e002242cb Mon Sep 17 00:00:00 2001
From: Corey Huink
ave to change. There's probably some
spacing/padding issues I haven't thought of. Please try it out, make some
modifications to existing document pages to see how badges would work in
those contexts.
From ded965fc90b223a834ac52d55512587b7a6ea139 Mon Sep 17 00:00:00 2001
From: Corey Hui
>
>
>> - Tab completion for \descibe-verbose.
>> I know that \d+ tab completion is also not there, but I think we must
>> have tab completion for \descibe-verbose.
>>
>> postgres=# \describe-
>> \describe-extension
>> \describe-replication-publication \describe-user-mapping
>> \describe-fo
>
>
> I agree with Andres and Robert. This patch should be pushed to PG13.
>
> I'll do that on March 8 unless there is a compelling argument not to.
>
>
No objection. I'll continue to work on it, though.
On Mon, Mar 4, 2019 at 1:45 PM Corey Huinker
wrote:
>
>>> - Tab completion for \descibe-verbose.
>>> I know that \d+ tab completion is also not there, but I think we must
>>> have tab completion for \descibe-verbose.
>>>
>>> postgres=# \
(moving this over from pgsql-performance)
A client had an issue with a where that had a where clause something like
this:
WHERE 123456 = ANY(integer_array_column)
I was surprised that this didn't use the pre-existing GIN index on
integer_array_column, whereas recoding as
WHERE ARRAY[123456] <@
On Thu, Mar 28, 2019 at 6:49 PM Peter Geoghegan wrote:
> On Thu, Mar 28, 2019 at 3:46 PM Jeremy Schneider
> wrote:
> > We're just gearing up for the Google Season of Docs and I think this
> > would be a great task for a doc writer to help with. Any reason to
> > expect serious objections to syn
On Sun, Mar 31, 2019 at 5:04 PM Andres Freund wrote:
> On 2019-04-01 09:52:34 +1300, Thomas Munro wrote:
> > +/*
> > + * This program is free software: you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Fou
>
> It seems this topic is ongoing so I've moved it to the September CF,
> but it's in "Waiting on Author" because we don't have a concrete patch
> that applies (or agreement on what it should do?) right now.
>
All recent work has been investigating the need(s) we're trying to address.
This is as
>
>
> > The people who expressed opinions on nuking triggers from orbit (it's
> the only way to be sure) have yet to offer up any guidance on how to
> proceed from here, and I suspect it's because they're all very busy getting
> things ready for v12. I definitely have an interest in working on this
A few months ago, I was researching ways for formalizing calling functions
on one postgres instance from another. RPC, basically. In doing so, I
stumbled across an obscure part of the the SQL Standard called ROUTINE
MAPPING, which is exactly what I'm looking for.
The syntax specified is, roughly:
>
> PostgreSQL allows function overloading, which means that there can be
> multiple functions with same name differing in argument types. So, the
> syntax has to include the input parameters or their types at least.
>
"local_routine_name" and "remote_routine_spec" were my own paraphrasings of
wha
>
>
>
> It goes on from there, but I think there's a reasonable interpretation
> of this which allows us to use the same syntax as CREATE
> (FUNCTION|PROCEDURE), apart from the body, e.g.:
>
> CREATE ROUTINE MAPPING local_routine_name
> FOR (FUNCTION | PROCEDURE) remote_routine_name ( [ [ argmode ]
> > CREATE ROUTINE MAPPING local_routine_name
> > > FOR (FUNCTION | PROCEDURE) remote_routine_name ( [ [ argmode ] [
> argname ]
> > > argtype [ { DEFAULT | = } default_expr ] [, ...] ] )
> > >[ RETURNS rettype
> > > | RETURNS TABLE ( column_name column_type [, ...] ) ]
> > > SERVER foreig
>
>
> >
> > But other situations seem un-handle-able to me:
> >
> > SELECT remote_func1(l.x) FROM local_table l WHERE l.active = true;
>
> Do we have any way, or any plan to make a way, to push the set (SELECT
> x FROM local_table WHERE active = true) to the remote side for
> execution there? Obvi
Some of the discussions about making psql more user friendly (more tab
completions help, exit, etc) got me thinking about other ways that psql
could be more friendly, and the one that comes to mind is our terse but
cryptic \d* commands.
I think it would be helpful and instructive to have correspon
>
> It would be about as hard to memorize \describe-schemas as it is to
> memorize \dn:
> You'd have to remember that it is "-" and not "_", that it is "describe",
> not "desc"
> and that it is "schemas", not "schema".
>
You wouldn't memorize them. You'd discover them with tab completion.
Type "
>
>
>\warn ...
>\warning ...
>
These two seem about the best to me, drawing from the perl warn command.
I suppose we could go the bash &2 route here, but I don't want to.
>
> One question is how to aggregate ranges that would leave gaps and/or
> overlaps. So in my extension there is a one-param version that forbids
> gaps & overlaps, but I let you permit them by passing extra parameters,
> so the signature is:
>
Perhaps a third way would be to allow and preserve th
>
>
> You can pass table name as text or table object id as regclass type.
>
> inside procedure you should to use dynamic sql - execute statement.
> Generally you cannot to use a variable as table or column name ever.
>
> Dynamic SQL is other mechanism - attention on SQL injection.
>
On this note,
>
>
>> Is there anything preventing us from having the planner resolve object
>> names from strings?
>>
>
> The basic problem is fact so when you use PREPARE, EXECUTE protocol, you
> has not parameters in planning time.
>
I agree that it defeats PREPARE as it is currently implemented with
PQprepar
For CTEs, is forcing inlining the example we want to give, rather than the
example of forcing materialization given?
According to the docs, virtual generated columns aren't yet supported. I'm
pretty sure the docs are right. Do we still want to mention it?
Otherwise it looks good to me.
On Tue, M
On Wed, Oct 10, 2018 at 1:44 AM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Tuesday, October 9, 2018, Imai, Yoshikazu <
> imai.yoshik...@jp.fujitsu.com> wrote:
>>
>> Are there any rows which can satisfy the ct's CHECK constraint? If not,
>> why we
>> allow creating table when check
On Thu, Oct 11, 2018 at 5:04 AM Surafel Temesgen
wrote:
>
>
> On Thu, Oct 11, 2018 at 12:00 PM Christoph Moench-Tegeder <
> c...@burggraben.net> wrote:
>
>> You can:
>> COPY ( query ) TO 'filename';
>>
> it is for COPY FROM
>
> regards
> Surafel
>
It didn't get far, but you may want to take a
>
> I think the code needs to be split up so that CopyFrom() in the loop
> body calls CopyFromOneTuple(), which then also splits out the tuple
> routing into its own CopyFromOneTupleRoute() function (that's 200 LOC on
> its own...). I suspect it'd also be good to refactor the
> partition-change cod
>
> >> A use case that I see quite a lot of is needing to do reports and other
> >> calculations on data per day/hour/etc but in the user's time zone. The
> >> way to do that is fairly trivial, but it's not obvious what it does so
> >> reading queries becomes just a little bit more difficult.
>
>
>
> > Are you thinking something like having a COPY command that provides
> > results in such a way that they could be referenced in a FROM clause
> > (perhaps a COPY that defines a cursor…)?
>
> That would also be nice, but what I was thinking of was that some
> highly restricted subset of cases o
>
>
> > SELECT x.a, sum(x.b)
> > FROM ( COPY INLINE '/path/to/foo.txt' FORMAT CSV ) as x( a integer, b
> numeric, c text, d date, e json) )
>
> Apologies for bike-shedding, but wouldn't the following be a better
> fit with the current COPY?
>
> COPY t(a integer, b numeric, c text, d date, e jso
On Fri, Nov 2, 2018 at 7:42 PM Alvaro Herrera
wrote:
> Here's a patch to allow partitioned tables to be referenced by foreign
> keys. Current state is WIP, but everything should work; see below for
> the expected exception.
>
> The design is very simple: have one pg_constraint row for each parti
>
>
> > 1. it seems that we will continue to to per-row RI checks for inserts and
> > updates. However, there already exists a bulk check in
> RI_Initial_Check().
> > Could we modify this bulk check to do RI checks on a per-statement basis
> > rather than a per-row basis?
>
> One of the goals when
>
> > 3. Radical alternative: Collapse everything into one new column. We
> > could combine atthasdef and attgenerated and even attidentity into a new
> > column. (Only one of the three can be the case.) This would give
> > client code a clean break, which may or may not be good. The
> > implem
>
> >>psql> \if :i >= 5
> >>
> > I think we're ok with that so long as none of the operators or values
> has a
> > \ in it.
> > What barriers do you see to re-using the pgbench grammar?
>
> The pgbench expression grammar mimics SQL expression grammar,
> on integers, floats, booleans & NULL.
>
>
>
>
> Or we could kill both issues by hard-wiring the separator as ','.
+1
I've never encountered a situation where a customer wanted a custom
delimiter AND quoted strings. So either they wanted pure CSV or a customed
TSV.
Could we have another output type called "separated" that uses the exist
On Sun, Nov 25, 2018 at 11:23 PM Tom Lane wrote:
> Corey Huinker writes:
> > Could we have another output type called "separated" that uses the
> existing
> > --fieldsep / --recordsep?
>
> Uh, what's the difference from the existing unaligned format?
>
On Mon, Jan 22, 2024 at 1:09 AM Peter Smith wrote:
> 2024-01 Commitfest.
>
> Hi, This patch has a CF status of "Needs Review" [1], but it seems
> there were CFbot test failures last time it was run [2]. Please have a
> look and post an updated version if necessary.
>
> ==
> [1] https://commit
LETE and
coming up empty.
Because the join syntax is subtly different between UPDATE and DELETE, I've
kept code examples in both, but the detailed explanation is in UPDATE under
the anchor "update-limit" and the DELETE example links to it.
From 298c812838491408e6910f7535067ea147abe5fc
>
>
>
> The patch set seem to be in a good shape and pretty stable for quite a
> while.
> Could you add one more minor improvement, a new line after variables
> declaration?
>
As you wish. Attached.
>
> After this changes, I think, we make this patch RfC, shall we?
>
>
Fingers crossed.
From bb55
On Wed, Feb 22, 2023 at 4:18 PM Thomas Munro wrote:
> On Tue, Jan 31, 2023 at 9:23 AM Corey Huinker
> wrote:
> >> Unfortunately, there is a fail in FreeBSD
> https://cirrus-ci.com/task/6466749487382528
> >>
> >> Maybe, this patch is need to be reba
On Wed, Feb 22, 2023 at 5:47 PM Andres Freund wrote:
> Hi,
>
> On 2023-02-22 16:34:44 -0500, Tom Lane wrote:
> > I wrote:
> > > Andres Freund writes:
> > >> Maybe it's worth sticking a StaticAssert() for the struct size
> > >> somewhere.
> >
> > > Indeed. I thought we had one already.
> >
> > >
On Thu, Feb 23, 2023 at 2:39 PM Andres Freund wrote:
> Hi,
>
> On 2023-02-23 13:56:56 -0500, Tom Lane wrote:
> > Corey Huinker writes:
> > > My not-ready-for-16 work on CAST( ... ON DEFAULT ... ) involved making
> > > FuncExpr/IoCoerceExpr/ArrayCoerceExp
On Thu, Feb 23, 2023 at 6:04 AM wrote:
> Hey,
>
> It depnends on scenario, but there is many use cases that hack data
> change from somebody with admin privileges could be disaster.
> That is the place where data history could come with help. Some basic
> solution would be trigger which writes p
On Thu, Feb 23, 2023 at 4:47 PM Nathan Bossart
wrote:
> On Thu, Feb 23, 2023 at 11:30:38AM -0800, Nathan Bossart wrote:
> > Will post a new version shortly.
>
> As promised...
>
> --
> Nathan Bossart
> Amazon Web Services: https://aws.amazon.com
Looks good to me, passes make check-world. Thanks
On Thu, Mar 2, 2023 at 1:35 PM Tom Lane wrote:
> Corey Huinker writes:
> > [ v9-0003-Add-psql-variables-SHELL_ERROR-and-SHELL_EXIT_COD.patch ]
>
> I took a brief look through this. I'm on board with the general
> concept, but I think you've spent too much time on an
On Fri, Mar 10, 2023 at 3:49 PM Tom Lane wrote:
> I'm okay with adopting bash's rule, but then it should actually match
> bash --- signal N is reported as 128+N, not -N.
>
128+N is implemented.
Nonzero pclose errors of any kind will now overwrite an existing exit_code.
I didn't write a formal
On Mon, Mar 20, 2023 at 1:01 PM Tom Lane wrote:
> Corey Huinker writes:
> > 128+N is implemented.
>
> I think this mostly looks OK, but:
>
> * I still say there is no basis whatever for believing that the result
> of ferror() is an exit code, errno code, or anything
>
>
> As you had it, any nonzero result would prevent backtick substitution.
> I'm not really sure how much thought went into the existing behavior,
> but I am pretty sure that it's not part of this patch's charter to
> change that.
>
> regards, tom lane
>
The changes all
>
>
> * 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,
>
> TBH I'm a bit afraid that people will immediately start complaining
> about the failing docs builds after this got applied since it forces
> them to add ids to all varlistenries in a variablelist if they add one,
> which can be perceived as quite a burden (also committers and reviewers
> will h
On Fri, Mar 24, 2023 at 11:07 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 20.03.23 19:31, Greg Stark wrote:
> > So I took a look at this patch. The conflict is with 2fe3bdbd691
> > committed by Peter Eisentraut which added error checks for pipes.
> > Afaics the behaviour i
On Fri, Mar 24, 2023 at 2:16 PM Corey Huinker
wrote:
>
>
> On Fri, Mar 24, 2023 at 11:07 AM Peter Eisentraut <
> peter.eisentr...@enterprisedb.com> wrote:
>
>> On 20.03.23 19:31, Greg Stark wrote:
>> > So I took a look at this patch. The conflict is with
On Tue, Mar 21, 2023 at 3:33 PM Corey Huinker
wrote:
>
>> As you had it, any nonzero result would prevent backtick substitution.
>> I'm not really sure how much thought went into the existing behavior,
>> but I am pretty sure that it's not part of this pa
23fc01215264d41b75d579c11bd22d2ec Mon Sep 17 00:00:00 2001
From: Corey Huinker
Date: Mon, 11 Mar 2024 14:18:39 -0400
Subject: [PATCH v9 1/2] Create pg_set_relation_stats, pg_set_attribute_stats.
These functions will be used by pg_dump/restore and pg_upgrade to convey
relation and attribute statisti
he dependency.
All those changes are available in the patches attached.
From ba411ce31c25193cf05bc4206dcb8f2bf32af0c7 Mon Sep 17 00:00:00 2001
From: Corey Huinker
Date: Mon, 11 Mar 2024 14:18:39 -0400
Subject: [PATCH v10 1/2] Create pg_set_relation_stats, pg_set_attribute_stats.
These functions
>
>
>
>
> From testrun/pg_dump/002_pg_dump/log/regress_log_002_pg_dump, search
> for the "not ok" and then look at what it tried to do right before
> that. I see:
>
> pg_dump: error: prepared statement failed: ERROR: syntax error at or
> near "%"
> LINE 1: ..._histogram => %L::real[]) coalesce($2,
tion usage more cleanly
- pg_set_*_stats function now have all of their parameters in the same
order as the table/view they pull from
From 5c63ed5748eb3817d193b64329b57dc590e0196e Mon Sep 17 00:00:00 2001
From: Corey Huinker
Date: Mon, 11 Mar 2024 14:18:39 -0400
Subject: [PATCH v11 1
On Thu, Mar 21, 2024 at 2:29 AM Jeff Davis wrote:
> On Tue, 2024-03-19 at 05:16 -0400, Corey Huinker wrote:
> > v11 attached.
>
> Thank you.
>
> Comments on 0001:
>
> This test:
>
>+SELECT
>+format('SELECT pg_catalog.pg_set_attribute_st
>
> How about just some defaults then? Many of them have a reasonable
> default, like NULL or an empty array. Some are parallel arrays and
> either both should be specified or neither (e.g.
> most_common_vals+most_common_freqs), but you can check for that.
>
+1
Default NULL has been implemented fo
>
>
>
> But ideally we'd just make it safe to dump and reload stats on your own
> tables, and then not worry about it.
>
That is my strong preference, yes.
>
> > Not off hand, no.
>
> To me it seems like inconsistent data to have most_common_freqs in
> anything but descending order, and we shoul
>
>
>
> +\gexec
>
> Why do we need to construct the command and execute? Can we instead
> execute the function directly? That would also avoid ECHO magic.
>
We don't strictly need it, but I've found the set-difference operation to
be incredibly useful in diagnosing problems. Additionally, the valu
>
> 1) The docs say this:
>
>
>The purpose of this function is to apply statistics values in an
>upgrade situation that are "good enough" for system operation until
>they are replaced by the next ANALYZE, usually via
>autovacuum This function is used by
>pg_upgrade and pg_res
>
>
> There's still a failure in the pg_upgrade TAP test. One seems to be
> ordering, so perhaps we need to ORDER BY the attribute number. Others
> seem to be missing relstats and I'm not sure why yet. I suggest doing
> some manual pg_upgrade tests and comparing the before/after dumps to
> see if y
On Fri, Mar 29, 2024 at 7:34 PM Jeff Davis wrote:
> On Fri, 2024-03-29 at 18:02 -0400, Stephen Frost wrote:
> > I’d certainly think “with stats” would be the preferred default of
> > our users.
>
> I'm concerned there could still be paths that lead to an error. For
> pg_restore, or when loading a
>
> (I've not read the patch yet, but I assume the switch works like
> other pg_dump filters in that you can apply it on the restore
> side?)
>
Correct. It follows the existing --no-something pattern.
>
> I'm getting late into this discussion and I apologize if I've missed this
> being discussed before. But.
>
> Please don't.
>
> That will make it *really* hard for any form of automation or drivers of
> this. The information needs to go somewhere where such tools can easily
> consume it, and an
>
> I didn't have any specific proposal in mind, was just trying to think
> outside the box.
>
What if we added a separate resection SECTION_STATISTICS which is run
following post-data?
>
> That will make it *really* hard for any form of automation or drivers of
> this. The information needs to go somewhere where such tools can easily
> consume it, and an informational message during runtime (which is also
> likely to be translated in many environments) is the exact opposite of th
On Sun, Mar 31, 2024 at 2:41 PM Tom Lane wrote:
> Corey Huinker writes:
> > Having given this some thought, I'd be inclined to create a view,
> > pg_stats_missing, with the same security barrier as pg_stats, but looking
> > for tables that lack stats on at least one c
1 - 100 of 444 matches
Mail list logo
