As of v11, DO blocks can do transactions. I think this will meet your needs.
A loop that starts at point X in the code and terminates at point Y has to
know how to jump back in the file (if there even is a file!) to point X and
re-interpret commands as it makes it's way back through the "file"
>> What you don't see here is that you're using your psql process's
>> available open file handles as a stack, and when you hit that limit psql
>> will fail. If you remove that limit, then you get a bit further before psql
>> segfaults on you. I think I got ~2700 files deep before that happened.
>
> Hope it is useful or interesting for someone! Questions or comments are
>> very welcome.
>>
>
> good idea.
>
> Regards
>
> Pavel
>
In a recent PgConf NYC presentation [1] I was talking about the technical
hurdles to implementing materialized views that could be kept up to date at
all times,
On Mon, Apr 30, 2018 at 7:05 AM Pierre Ducroquet <
pierre.ducroq...@people-doc.com> wrote:
> On Monday, April 30, 2018 1:01:25 PM CEST Daniel Verite wrote:
> > Corey Huinker wrote:
> > > As of v11, DO blocks can do transactions. I think this will meet your
> >
>
>
> I did it too. It is not too hard - there was not a agreement on syntax.
>
> can be nice some like CTE
>
> WITH PROCEDURE x(a int, b int) AS ... $$ SELECT x(10);
>
I've seen "WITH function" syntax in Oracle (here's an example:
> > 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
>
> 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
>
> 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
>
>
>
> 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
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:
>
> You appear to be saying that you think that renaming an index
> concurrently is not safe. In that case, this patch should be rejected.
> However, I don't think it necessarily is unsafe. What we need is some
> reasoning about the impact, not a bunch of different options that we
> don't
On Mon, Sep 10, 2018 at 3:28 AM Hannu Krosing
wrote:
> Hi Corey
>
> Have you looked at pl/proxy ?
>
I have, a long while ago.
> It does this and then some (sharding)
>
PL/proxy isn't a part of the SQL Standard.
PL/proxy only connects to other libpq-speaking databases.
The hope with routine
>
>
>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?
>
> 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
>
> >> 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.
>
>
>
>
> > 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
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
>
> > 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
>
>
> > 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
> >
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
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
Attached is a patch that refactors DELETE triggers to fire at the statement
level.
I chose delete triggers partly out of simplicity, and partly because there
some before/after row linkage in the ON UPDATE CASCADE cases where
statement level triggers might not be feasible as we have currently
Back when Pg added statement-level triggers, I was interested in the
potential promise of moving referential integrity checks to statement-level
triggers.
The initial conversation, along with Kevin Grittner's POC script (in SQL)
that showed a potential for a 98% reduction in time spent doing RI
In digging around the codebase (see thread: Referential Integrity Checks
with Statement-level Triggers), I noticed that unique constraints are
similarly enforced with a per-row trigger.
The situation with unique indexes is fairly similar to the situation with
RI checks: there is some overhead to
| 0 || \x ||
| pg_inserted_transition_table
(2 rows)
Any idea where I went wrong?
On Mon, Dec 17, 2018 at 9:56 AM Corey Huinker
wrote:
> In digging around the codebase (see thread: Referential Integrity Checks
> with Statement-level Triggers), I noticed that
>
> >>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.
>
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?
>
No f
>
>
> 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
On Fri, Jan 4, 2019 at 7:49 AM Peter Eisentraut
wrote:
>
> On 25/12/2018 00:56, Corey Huinker wrote:
> > The regression diff (attached) seems to imply that the triggers simply
> > are not firing, though.
>
> The reason for this was explained by Dean. If you take out the c
e've got wins all around.
>
> Best,
> David.
> --
> David Fetter http://fetter.org/
> Phone: +1 415 235 3778
>
> Remember to vote!
> Consider donating to Postgres: http://www.postgresql.org/about/donate
>
From e67e61ae789b09c98fe03378c819224d838c2f65 Mon Sep 17
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
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
On Fri, Feb 22, 2019 at 1:12 PM Corey Huinker
wrote:
> On Fri, Feb 22, 2019 at 11:05 AM Peter Eisentraut <
> peter.eisentr...@2ndquadrant.com> wrote:
>
>> ri_triggers.c is endlessly long and repetitive. I want to clean it up a
>> bit (more).
>>
>
> H
>
> Given that this patch has been added to the last commitfest for v12, I
> think we should mark it as targeting 13, so it can be skipped over by
> people looking to get things into v12. Even leaving fairness aside, I
> don't think it's likely to be ready quickly enough...
>
Obviously this
>
>
> In order to avoid per-row calls of the constraint trigger functions, we
> could
> try to "aggregate" the constraint-specific events somehow, but I think a
> separate queue would be needed for the constraint-specific events.
>
> In general, the (after) triggers and constraints have too much
>
>
>> - 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
>>
>
>
> While the idea to use the transition table is good, this approach probably
> requires the trigger engine (trigger.c) to be adjusted, and that in a
> non-trivial way.
>
It probably does. Several people with advanced knowledge of trigger.c
expressed a desire to rebuild trigger.c from the
On Fri, Feb 22, 2019 at 11:05 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> ri_triggers.c is endlessly long and repetitive. I want to clean it up a
> bit (more).
>
Having just been down this road, I agree that a lot of cleanup is needed
and possible.
> I looked into all
>
>
> 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.
>
> Right, this makes a lot of sense, similar to how ri_restrict() combines
> RESTRICT and NO ACTION.
>
I'm pretty sure that's where I got the idea, yes.
(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 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=# \
> Otherwise "\g -" looks good as a portable solution.
+1
>
> > So what is the uptake on implementing this at the server side, ie.
> > DESCRIBE?
>
> I'm pretty skeptical of this idea, unless you are willing to throw
> away at least one and possibly both of the following goals:
>
> 1. Compatibility with psql's existing \d behavior.
>
I don't think
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,
>
>
>> 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
>
>
> 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
>
> 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
On Fri, Jul 5, 2019 at 12:32 PM David Fetter wrote:
> Folks,
>
> Corey Huinker put together the documentation for this proposed
> feature. Does this seem like a reasonable way to do it?
>
>
In doing that work, it became clear that the command was serving two
masters:
>
>
>\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.
>
>
> >- @> 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
>
>
>
> > 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
>
> 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
>
> I should probably split this into "actionable" (categories 3 and 4)
> and "noise and scaffolding" patches.
>
Breaking down the noise-and-scaffolding into some subgroups might make the
rather long patches more palatable/exceedingly-obvious:
* (Datum) 0 ---> NullDatum
* 0 > NullDatum
* The
>
> The thing that most approaches to this have fallen down on is triggers ---
> that is, a trigger function might access columns mentioned nowhere in the
> SQL text. (See 8b6da83d1 for a recent example :-() If you have a plan
> for dealing with that, then ...
>
Well, if we had a trigger
'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 Huinker
Date: Fri, 18 Oct 2019 0
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 Huinker
Date: Sun, 13 Oct 2019 17:57:36
ventually found the time to take a second
pass at this.
Attached is a revised patch.
From f087e44fe4db7996880cf4df982297018d444363 Mon Sep 17 00:00:00 2001
From: Corey Huinker
Date: Wed, 12 Feb 2020 04:17:59 +
Subject: [PATCH] add glossary page with initial definitions
---
doc/src/sgml/filelist.sg
>
> A possible gotcha in this approach is if there are any python 2/3
> incompatibilities that would not manifest as syntax errors or
> obvious runtime errors, but would allow old code to execute and
> silently do the wrong thing. One would hope that the Python crowd
> weren't dumb enough to do
>
> So, as with Jesse's example, what I'm wondering is whether or not 2to3
> will fix that for you (or even flag it). The basic difference between
> the two alternatives I suggested is whether we force people to put their
> python function through that converter before we'll even try to run it.
>
e can link to the glossary from
outside if we so choose.
I encourage everyone to read the definitions, and suggest fixes to any
inaccuracies or awkward phrasings. Mostly, though, I'm seeking feedback on
the structure itself, and hoping to get that committed.
On Tue, Feb 11, 2020 at 11:22 PM Cor
>
>
> * Transaction - yes, all those things could be "visible" or they could be
> "side effects". It may be best to leave the over-simplified definition in
> place, and add a "For more information see < tutorial-transactions>>
>
transaction-iso would be a better linkref in this case
>
> It will be helpful for diff-ing to restrict the length of lines in the
> SGML files to 71 characters (as usual).
I did it that way for the following reasons
1. It aids grep-ability
2. The committers seem to be moving towards that for SQL strings, mostly
for reason #1
3. I recall that the
On Wed, Mar 11, 2020 at 12:50 PM Jürgen Purtz wrote:
> I made changes on top of 0001-add-glossary-page.patch which was supplied
> by C. Huinker. This affects not only terms proposed by me but also his
> original terms. If my changes are not obvious, please let me know and I
> will describe my
On Wed, Apr 8, 2020 at 1:06 PM Pavel Stehule
wrote:
>
>
> st 8. 4. 2020 v 18:36 odesílatel Antonin Houska napsal:
>
>> After having reviewed [1] more than a year ago (the problem I found was
>> that
>> the transient table is not available for deferred constraints), I've
>> tried to
>> implement
>
> Yeah, back at the beginning of this exercise, Alvaro wondered aloud
> if we should go to something other than tables altogether. I dunno
> what that'd look like though.
>
It would probably look like our acronyms and glossary pages.
Maybe the return example and return values get replaced
>
> Thinking out loud, it'd also be great if we could add in some anchors as
> well, so perhaps in the future on the pgweb side we could add in some
> discoverable links that other documentation has -- which in turn people
> could click / link to others directly to the function name.
>
+1
>
>
> Term 'relation': A sequence is internally a table with one row - right?
> Shall we extend the list of concrete relations by 'sequence'? Or is this
> not necessary because 'table' is already there?
>
I wrote one for sequence, it was a bit math-y for Alvaro's taste, so we're
going to try
>
> I can imagine removal of the SPI from the current implementation (and
> constructing the plans "manually"), but note that the queries I use in my
> patch are no longer that trivial. So the SPI makes sense to me because it
> ensures regular query planning.
>
As an intermediate step, in the
On Sat, Apr 4, 2020 at 2:55 AM Fabien COELHO wrote:
>
> > BTW it's now visible at:
> > https://www.postgresql.org/docs/devel/glossary.html
Nice. I went looking for it yesterday and the docs hadn't rebuilt yet.
> ISTM that occurrences of these words elsewhere in the documentation should
>
On Thu, Apr 2, 2020 at 8:44 AM Jürgen Purtz wrote:
> +1 and many thanks to Alvaros edits.
>
>
I did some of the grunt work Alvaro alluded to in v6, and the results are
attached and they build, which means there are no invalid links.
Notes:
* no definition wordings were changed
* added a linkend
>
> we have it, we can start thinking of patching the main part of the docs
> to make reference to it by using in key spots. Right now
> the glossary links to itself, but it makes lots of sense to have other
> places point to it.
>
I have some ideas about how to patch the main docs, but will
On Tue, Mar 31, 2020 at 2:09 PM Justin Pryzby wrote:
> On Sun, Oct 13, 2019 at 04:52:05PM -0400, Corey Huinker wrote:
> > 1. It's obviously incomplete. There are more terms, a lot more, to add.
>
> How did you come up with the initial list of terms ?
>
1. I asked some new
On Sun, Mar 29, 2020 at 5:29 AM Jürgen Purtz wrote:
> On 27.03.20 21:12, Justin Pryzby wrote:
> > On Fri, Mar 20, 2020 at 11:32:25PM +0100, Jürgen Purtz wrote:
> +Archiver
> >>> Can you change that to archiver process ?
> >> I prefer the short term without the addition of 'process' -
>
> I propose we define "planner" and make "optimizer" a entry.
>
I have no objection to more entries, or edits to entries, but am concerned
that the process leads to someone having to manually merge several
start-from-scratch patches, with no clear sense of when we'll be done. I
may make sense
>
> 2. I found out that "see xyz" and "see also" have bespoke markup in
> Docbook -- and . I changed some glossentries
> to use those, removing some glossdefs and changing a couple of paras to
> glossseealsos. I also removed all "id" properties from glossentries
> that are just , because I
On Wed, Apr 29, 2020 at 10:34 AM Jonah H. Harris
wrote:
> On Wed, Apr 29, 2020 at 7:22 AM Peter Eisentraut <
> peter.eisentr...@2ndquadrant.com> wrote:
>
>> Yeah the RECURSIVE vs ITERATIVE is a bit of a red herring here. As you
>> say, the RECURSIVE keyword doesn't specify the processing but
On Wed, Apr 29, 2020 at 3:15 PM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> Why are all the glossary terms capitalized? Seems kind of strange.
>
>
They weren't intended to be, and they don't appear to be in the page I'm
looking at. Are you referring to the anchor like in
>
>
> > Perhaps something like this would be more readable
> >
> > WITH t AS (
> >UPDATE ( SELECT 1 AS ctr, 'x' as val )
> >SET ctr = ctr + 1, val = val || 'x'
> >WHILE ctr <= 100
> >RETURNING ctr, val
> > )
> >
> > The notion of an UPDATE on an ephemeral subquery isn't that
On Wed, Apr 22, 2020 at 2:36 PM Andres Freund wrote:
> Hi,
>
> On 2020-04-22 13:46:22 -0400, Robert Haas wrote:
> > On Wed, Apr 22, 2020 at 1:18 PM Alvaro Herrera
> wrote:
> > > Well, I was actually thinking in building ready-made execution trees,
> > > bypassing the planner altogether. But
>
>
> >
> > Please do list Jürgen, Corey and Roger as authors of the glossary.
>
> (Actually I should be listed as well, as the time I spent on it was
> considerable.)
>
+1, the time spent was quite considerable
On Fri, Mar 13, 2020 at 12:18 AM Jürgen Purtz wrote:
>
> The statement that names of schema objects are unique isn't *strictly* true,
> just *mostly* true. Take the case of a unique constraints.
>
> Concerning CONSTRAINTS you are right. Constraints seems to be an exception:
>
>- Their name
On Thu, Mar 19, 2020 at 8:11 PM Alvaro Herrera
wrote:
> I gave this a look. I first reformatted it so I could read it; that's
> 0001. Second I changed all the long items into s, which
>
Thanks! I didn't know about xrefs, that is a big improvement.
> are shorter and don't have to repeat the
>
> Jürgen mentioned off-list that the man page doesn't build. I was going to
>> look into that, but if anyone has more familiarity with that, I'm listening.
>>
>
Looking at this some more, I'm not sure anything needs to be done for man
pages. man1 is for executables, man3 seems to be dblink and
>
> It's hard to review work from a professional tech writer. I'm under the
> constant impression that I'm ruining somebody's perfect end product,
> making a fool of myself.
If it makes you feel better, it's a mix of definitions I wrote that Roger
proofed and restructured, ones that Jürgen had
On Fri, Mar 20, 2020 at 6:32 PM Jürgen Purtz wrote:
> man pages: Sorry, if I confused someone with my poor English. I just
> want to express in my 'offline' mail that we don't have to worry about
> man page generation. The patch doesn't affect files in the /ref
> subdirectory from where man
>
> Perhaps this is what you mean by "deterministic", but isn't it
> possible for some collations to treat multiple byte sequences as equal
> values? And those multiple byte sequences wouldn't necessarily occur
> sequentially in C collation, so it wouldn't be possible to work around
> that by
>
>
> > > + Records to the file system and creates a special
> >
> > Does the chckpointer actually write WAL ?
>
> Yes.
>
> > An FK doesn't require the values in its table to be unique, right ?
>
> I believe it does require that the values are unique.
>
> > I think there's some confusion.
>
> 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
>> One limitation of this approach is that \set can't span lines, so
>> writing complex queries would be kinda painful. But that would
>> be a good limitation to address separately; \set isn't the only
>> metacommand where can't-span-lines is a problem sometimes.
>> If you seriously want to
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.
>
&
>
> 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
>
>
>
> 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
>
> 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
>
> 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
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 =
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,
>
>
>
> 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
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
>>
1 - 100 of 308 matches
Mail list logo