Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0

(2019/01/19 21:17), Amit Langote wrote: On Fri, Jan 18, 2019 at 9:58 PM Etsuro Fujita wrote: I updated the patch as such and rebased it to the latest HEAD. I also added the commit message. Attached is an updated patch. Does that make sense? If there are no objections, I'll push that patch

Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0

On 2019/01/21 17:17, Etsuro Fujita wrote: > (2019/01/19 21:17), Amit Langote wrote: >> On Fri, Jan 18, 2019 at 9:58 PM Etsuro Fujita >>   wrote: >>> I updated the patch as such and rebased it to the latest HEAD.  I also >>> added the commit message.  Attached is an updated patch.  Does that make >>

Re: partitioned tables referenced by FKs

Hi Alvaro, On 2018/12/01 4:12, Alvaro Herrera wrote: > Here's a more credible version of this patch series. Are you going to post rebased patches soon? Thanks, Amit

Re: Protect syscache from bloating with negative cache entries

Thank you for pointing out the stupidity. (Tom did earlier, though.) At Mon, 21 Jan 2019 07:12:41 +, "Tsunakawa, Takayuki" wrote in <0A3221C70F24FB45833433255569204D1FB6C78A@G01JPEXMBYT05> > From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp] > > 0003: Remote GUC setting > > >

Re: Pluggable Storage - Andres's take

On Sun, 20 Jan 2019 at 22:46, Dmitry Dolgov <9erthali...@gmail.com> wrote: > > > On Fri, Jan 18, 2019 at 11:22 AM Amit Khandekar > > wrote: > > > > --- a/src/test/regress/expected/copy2.out > > +++ b/src/test/regress/expected/copy2.out > > @@ -1,3 +1,4 @@ > > +\set HIDE_TABLEAM on > > > > I thoug

Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0

(2019/01/21 17:21), Amit Langote wrote: On 2019/01/21 17:17, Etsuro Fujita wrote: (2019/01/19 21:17), Amit Langote wrote: On Fri, Jan 18, 2019 at 9:58 PM Etsuro Fujita wrote: I updated the patch as such and rebased it to the latest HEAD. I also added the commit message. Attached is an upd

Re: Allowing extensions to find out the OIDs of their member objects

On Sun, Jan 20, 2019 at 06:50:33PM -0500, Tom Lane wrote: > A larger issue is whether "hand out some OIDs on-demand" is a > sustainable strategy. I think that it is, if we encourage extensions > to assign fixed OIDs only to objects they really need to. In thirty-ish > years of core PG development

Re: [PATCH] pgbench tap tests fail if the path contains a perl special character

Hello Tom, Hm, so bowerbird (a Windows machine) has been failing the pgbench tests since this went in, cf https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2019-01-20%2004%3A57%3A01 I'm just guessing, but I suspect that bowerbird is using a path spec that includes a backsl

Re: New vacuum option to do only freezing

On Sat, Jan 19, 2019 at 5:08 AM Robert Haas wrote: > > On Thu, Jan 17, 2019 at 1:57 AM Masahiko Sawada wrote: > > The reason why I processed the tuples that became dead after the first > > heap pass is that I was not sure the reason why we ignore such tuples > > in the second heap pass despite of

libpq environment variables in the server

When libpq is loaded in the server (libpqwalreceiver, dblink, postgres_fdw), it may use libpq environment variables set in the postmaster environment for connection parameter defaults. I have noticed that this has some confusing effects in our test suites. I wonder if this is a good idea in gener

"ALTER TRIGGER .. RENAME TO" broken with the "Remove WITH OIDS" commit.

Hi, I found that ALTER TRIGGER .. RENAME TO is broken and it's unable to rename the trigger. Looking further seems renametrig() function, copy the new trigger name into wrong tuple. This is broken with below commit: commit 578b229718e8f15fa779e20f086c4b6bb3776106 Author: Andres Freund Date:

Re: WIP: Avoid creation of the free space map for small tables

On Sun, Jan 20, 2019 at 5:19 AM John Naylor wrote: > Review of v16-0002-During-pg_upgrade-conditionally-skip-transfer-of: - * Copy/link any fsm and vm files, if they exist + * Copy/link any fsm and vm files, if they exist and if they would + * be created in the new cluster. */ - transfer_relfi

Re: [PROPOSAL] Shared Ispell dictionaries

On 21.01.2019 02:43, Tomas Vondra wrote: On 1/20/19 11:21 PM, Andres Freund wrote: On 2019-01-20 23:15:35 +0100, Tomas Vondra wrote: Thanks. I've reviewed v17 today and I haven't discovered any new issues so far. If everything goes fine and no one protests, I plan to get it committed over the n

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

On Mon, Nov 26, 2018 at 9:33 PM Dmitry Dolgov <9erthali...@gmail.com> wrote: > > On Mon, Nov 26, 2018 at 1:41 PM Dmitry Dolgov <9erthali...@gmail.com> > wrote: > > > > Thanks, I've messed this up too - rebased a wrong branch, the correct one > > doesn't have this code already. Sorry for that, and

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

(2019/01/21 20:56), amul sul wrote: On Mon, Nov 26, 2018 at 9:33 PM Dmitry Dolgov <9erthali...@gmail.com > wrote: > On Mon, Nov 26, 2018 at 1:41 PM Dmitry Dolgov <9erthali...@gmail.com > wrote: > > Thanks, I've messed

Re: Alternative to \copy in psql modelled after \g

Fabien COELHO wrote: > sql> SELECT 1 \g /BAD > /BAD: Permission denied > > sql> \echo :ERROR > false That seems broken, because it's pointless to leave out a class of errors from ERROR. Presumably the purpose of ERROR is to enable error checking like: \if :ERROR ... error p

Procedures with out parameter(Postgresql 11)

Hi, Please let me know how to deal with procedures with out parameter and returning out parameters. Thanks & Regards Navneet maddheshiya

Re: Procedures with out parameter(Postgresql 11)

Hi po 21. 1. 2019 13:57 odesílatel navneet nikku napsal: > Hi, > Please let me know how to deal with procedures with out parameter and > returning out parameters. > only out parameters are not supported. Use inout instead. regards Pavel Thanks & Regards > Navneet maddheshiya >

Re: Alternative to \copy in psql modelled after \g

Fabien COELHO wrote: > (1) document ERROR as being muddy, i.e. there has been some error which > may be SQL or possibly client side. Although SQLSTATE would still allow to > know whether an SQL error occured, there is still no client side > expressions, and even if I had moved pgbench e

Re: Early WIP/PoC for inlining CTEs

On 1/18/19 9:34 PM, Robert Haas wrote: On Thu, Jan 17, 2019 at 10:48 AM Andreas Karlsson wrote: On 1/11/19 8:10 PM, Robert Haas wrote: WITH cte_name [[NOT] MATERIALIZED] AS (query) main_query... Hm, when would one want "NOT MATERIALIZED"? I am not sure I see the usefulness of forcing inlinin

Re: jsonpath

On 20.01.2019 2:45, Alexander Korotkov wrote: 3) How do we calculate the "id" property returned by keyvalue() function? It's not documented. Even presence of "id" columns isn't documented. Standard stands that it's implementation-depended indetifier of object holding key-value pair. The way

Re: House style for DocBook documentation?

On 2019-Jan-19, Chapman Flack wrote: > I have noticed a couple of things: > > - 'SQL' is often marked up as SQL, but far from always. > > - no such markup is applied to 'JSON' or 'XML' at all, at least > not in func.sgml. I think these inconsistencies just stem from lack of a strong reviewer h

Re: speeding up planning with partitions

Hi, On 1/21/19 4:01 AM, Amit Langote wrote: Rebased again due to 8d8dcead1295. Passes check-world on 8d8dcead1295. I ran a work load on the series, measuring the time to load the data plus the run-time to complete the work load. LoadRun master3m39s 144s 1778 3m12s

Re: [PROPOSAL] Shared Ispell dictionaries

On 1/21/19 12:51 PM, Arthur Zakirov wrote: > On 21.01.2019 02:43, Tomas Vondra wrote: >> On 1/20/19 11:21 PM, Andres Freund wrote: >>> On 2019-01-20 23:15:35 +0100, Tomas Vondra wrote: Thanks. I've reviewed v17 today and I haven't discovered any new issues so far. If everything goes fine

Re: jsonpath

On Mon, Jan 21, 2019 at 1:40 AM Alexander Korotkov wrote: > > On Sun, Jan 20, 2019 at 6:30 AM Alexander Korotkov > wrote: > > I'll continue revising this patchset. Nikita, could you please write > > tests for 3-argument versions of functions? Also, please answer the > > question regarding "id"

Re: COPY FROM WHEN condition

On 1/21/19 4:33 AM, Tomas Vondra wrote: > > > On 1/21/19 3:12 AM, Andres Freund wrote: >> On 2019-01-20 18:08:05 -0800, Andres Freund wrote: >>> On 2019-01-20 21:00:21 -0500, Tomas Vondra wrote: On 1/20/19 8:24 PM, Andres Freund wrote: > Hi, > > On 2019-01-20 00:24:05

Re: Early WIP/PoC for inlining CTEs

Andreas Karlsson writes: > I have a minor biksheddish question about the syntax. > You proposed: > WITH cte_name [[NOT] MATERIALIZED] AS (query) main_query > While Andrew proposed: > WITH cte_name AS [[NOT] MATERIALIZED] (query) main_query > Do people have any preference between these two? FWIW,

Re: [PATCH] pgbench tap tests fail if the path contains a perl special character

On 1/21/19 4:50 AM, Fabien COELHO wrote: > > Hello Tom, > >> Hm, so bowerbird (a Windows machine) has been failing the pgbench tests >> since this went in, cf >> >> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2019-01-20%2004%3A57%3A01 >> >> >> I'm just guessing, but I sus

Re: [PATCH] pgbench tap tests fail if the path contains a perl special character

Andrew Dunstan writes: > Perhaps it would be OK we changed back the glob line to use $prefix > instead of $qprefix, but kept the use of $qprefix in the later regex. Well, glob does have some metacharacters, so not doing any quoting at all still leaves us with failure modes. I did a little bit of

Re: [PATCH] pgbench tap tests fail if the path contains a perl special character

Hello Andrew, About windows-specific issues, from File::Glob man page: """ On DOSISH systems, backslash is a valid directory separator character. In this case, use of backslash as a quoting character (via GLOB_QUOTE) interferes with the use of backslash as a directory separator. ... """ It se

Re: [PATCH] pgbench tap tests fail if the path contains a perl special character

Hello Tom, Well, glob does have some metacharacters, so not doing any quoting at all still leaves us with failure modes. I did a little bit of googling on this subject last night, and it seems that at least some people believe that the answer is to not use glob, period, but read the directory

Re: [PATCH] pgbench tap tests fail if the path contains a perl special character

On 1/21/19 11:18 AM, Fabien COELHO wrote: > > Hello Tom, > >> Well, glob does have some metacharacters, so not doing any quoting >> at all still leaves us with failure modes. >> >> I did a little bit of googling on this subject last night, and it >> seems that at least some people believe that th

Re: [PROPOSAL] Shared Ispell dictionaries

On 21.01.2019 17:56, Tomas Vondra wrote: On 1/21/19 12:51 PM, Arthur Zakirov wrote: I'll try to implement the syntax, you suggested earlier: ALTER TEXT SEARCH DICTIONARY x UNLOAD/RELOAD The main point here is that UNLOAD/RELOAD can't release the memory immediately, because some other backend m

Re: House style for DocBook documentation?

On 01/21/19 09:12, Alvaro Herrera wrote: >> (thinks to self half-seriously about an XSL transform for generating >> printed output that could preserve link-texted links, add raised numbers, >> and produce a numbered URLs section at the back) > > Well, if you have the time and inclination, and you

Re: pgsql: Remove references to Majordomo

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Magnus Hagander writes: > > On Sat, Jan 19, 2019 at 7:19 PM Stephen Frost wrote: > >> Does this also implicitly mean we've just agreed to push back the > >> retirement of the @postgresql.org aliases for the lists until v11 is > >> EOL..? > > >

Re: House style for DocBook documentation?

On 1/21/19 8:46 AM, Chapman Flack wrote: On 01/21/19 09:12, Alvaro Herrera wrote: (thinks to self half-seriously about an XSL transform for generating printed output that could preserve link-texted links, add raised numbers, and produce a numbered URLs section at the back) Well, if you have th

Re: Thread-unsafe coding in ecpg

"Tsunakawa, Takayuki" writes: > From: Tom Lane [mailto:t...@sss.pgh.pa.us] >> So like this ... > How quick! Thank you. I've reviewed the code for both Unix and Windows, and > it looks OK. I haven't built the patch, but expect the buildfarm to do the > test. Thanks for reviewing! I've pushe

Re: "ALTER TRIGGER .. RENAME TO" broken with the "Remove WITH OIDS" commit.

Hi, On 2019-01-21 17:02:15 +0530, Rushabh Lathia wrote: > Hi, > > I found that ALTER TRIGGER .. RENAME TO is broken and it's > unable to rename the trigger. Looking further seems renametrig() > function, copy the new trigger name into wrong tuple. This is > broken with below commit: > > commit

Re: jsonpath

On Mon, Jan 21, 2019 at 6:05 PM Oleg Bartunov wrote: > On Mon, Jan 21, 2019 at 1:40 AM Alexander Korotkov > wrote: > > > > On Sun, Jan 20, 2019 at 6:30 AM Alexander Korotkov > > wrote: > > > I'll continue revising this patchset. Nikita, could you please write > > > tests for 3-argument versions

Re: tickling the lesser contributor's withering ego

On 2018-Dec-27, Magnus Hagander wrote: > On Fri, Dec 21, 2018 at 4:17 PM Alvaro Herrera > wrote: > > > On 2018-Dec-21, Tom Lane wrote: > > > > > Alvaro Herrera writes: > > > > I propose the following patch, which will make those links stable -- > > > > then we can add the following links to the

Re: Thread-unsafe coding in ecpg

> Thanks for reviewing! I've pushed this now (to HEAD only for the > moment), > we'll see what the buildfarm thinks. > > BTW, I found another spot in descriptor.c where ecpglib is using > setlocale() for the same purpose. Perhaps that one's not reachable > in threaded apps, but I didn't see any

Re: Simplify set of flags used by MyXactFlags

On 2019-Jan-18, Michael Paquier wrote: > Keeping both messages makes the error handling at PREPARE time perhaps > a bit cleaner to make the difference about schema-level access or > table-level access, still I'd rather simplify the code and just only > keep the schema-level change as something we

Re: House style for DocBook documentation?

On 2019-Jan-21, Chapman Flack wrote: > But the point's well taken that in /printed output/, that's of no use. > Which is, in a sense, an inconsistency: in one format, you can follow the > links, while in another, you're out of luck. > > Maybe a simpler transform for printed output, rather than co

Re: House style for DocBook documentation?

On 01/21/19 12:07, Joshua D. Drake wrote: > Who is really going to "print" our docs? If they do print the > docs, they are likely not going to "type in" a long URL. QR code in footnote (ducks and runs).

Re: House style for DocBook documentation?

On 1/21/19 10:01 AM, Alvaro Herrera wrote: On 2019-Jan-21, Chapman Flack wrote: But the point's well taken that in /printed output/, that's of no use. Which is, in a sense, an inconsistency: in one format, you can follow the links, while in another, you're out of luck. Maybe a simpler transfor

Re: House style for DocBook documentation?

On 1/21/19 10:11 AM, Chapman Flack wrote: On 01/21/19 12:07, Joshua D. Drake wrote: Who is really going to "print" our docs? If they do print the docs, they are likely not going to "type in" a long URL. QR code in footnote (ducks and runs). Funny, although I know why you said that. I don't th

Re: House style for DocBook documentation?

On 2019-Jan-21, Joshua D. Drake wrote: > On 1/21/19 10:01 AM, Alvaro Herrera wrote: > > On 2019-Jan-21, Chapman Flack wrote: > > > > > But the point's well taken that in /printed output/, that's of no use. > > > Which is, in a sense, an inconsistency: in one format, you can follow the > > > links

Re: COPY FROM WHEN condition

Hi, On 2019-01-21 16:22:11 +0100, Tomas Vondra wrote: > > > On 1/21/19 4:33 AM, Tomas Vondra wrote: > > > > > > On 1/21/19 3:12 AM, Andres Freund wrote: > >> On 2019-01-20 18:08:05 -0800, Andres Freund wrote: > >>> On 2019-01-20 21:00:21 -0500, Tomas Vondra wrote: > > > On 1/20/

Re: What to name the current heap after pluggable storage / what to rename?

On 2019-01-18 14:19:41 -0800, Andres Freund wrote: > Hi, > > On 2019-01-16 08:20:37 -0800, Andres Freund wrote: > > On January 16, 2019 8:08:09 AM PST, Robert Haas > > wrote: > > >On Tue, Jan 15, 2019 at 10:23 PM Haribabu Kommi > > > wrote: > > >> access/relation.[c|h] name is fine. Or how about

Re: House style for DocBook documentation?

On 01/21/19 13:14, Joshua D. Drake wrote: >> Of course, the text would also be clickable, right? I think putting the >> URL in a footnote is good in that case; it works both on screen and on >> paper, which should alleviate JD's concerns. > > Yeah I could see that. I thought about that but was wo

should ConstraintRelationId ins/upd cause relcache invals?

Hello While working on bugfixes for FK problems in partitioned tables, I came across some behavior that appears to stem from our inclusion of foreign keys in relcache, without sufficient care for invalidating the relcache entries when the foreign key set for the table changes. (Namely, a partitio

Re: should ConstraintRelationId ins/upd cause relcache invals?

Hi, On 2019-01-21 16:27:50 -0300, Alvaro Herrera wrote: > While working on bugfixes for FK problems in partitioned tables, I came > across some behavior that appears to stem from our inclusion of foreign > keys in relcache, without sufficient care for invalidating the relcache > entries when the f

Re: Thread-unsafe coding in ecpg

On 2019-01-21 12:09:30 -0500, Tom Lane wrote: > "Tsunakawa, Takayuki" writes: > > From: Tom Lane [mailto:t...@sss.pgh.pa.us] > >> So like this ... > > > How quick! Thank you. I've reviewed the code for both Unix and Windows, > > and it looks OK. I haven't built the patch, but expect the build

Re: Thread-unsafe coding in ecpg

Andres Freund writes: > Seems jacana might not have like this change? > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana&dt=2019-01-21%2019%3A01%3A28 Hmm. So mingw doesn't provide access to _configthreadlocale(). That's unfortunate, at least if we think that mingw is still a viable

Re: should ConstraintRelationId ins/upd cause relcache invals?

Alvaro Herrera writes: > While working on bugfixes for FK problems in partitioned tables, I came > across some behavior that appears to stem from our inclusion of foreign > keys in relcache, without sufficient care for invalidating the relcache > entries when the foreign key set for the table chan

Re: Thread-unsafe coding in ecpg

On 1/21/19 12:05 PM, Tom Lane wrote: Andres Freund writes: Seems jacana might not have like this change? https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana&dt=2019-01-21%2019%3A01%3A28 Hmm. So mingw doesn't provide access to _configthreadlocale(). That's unfortunate, at least if w

Re: Thread-unsafe coding in ecpg

Hi, On 2019-01-21 15:05:23 -0500, Tom Lane wrote: > Andres Freund writes: > > Seems jacana might not have like this change? > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana&dt=2019-01-21%2019%3A01%3A28 > > Hmm. So mingw doesn't provide access to _configthreadlocale(). > That's

Re: Thread-unsafe coding in ecpg

"Joshua D. Drake" writes: > On 1/21/19 12:05 PM, Tom Lane wrote: >> Is there a newer version of mingw that does have this functionality? > Apparently this can be done with thee 64bit version: > https://stackoverflow.com/questions/33647271/how-to-use-configthreadlocale-in-mingw Hmm, the followup

Re: Thread-unsafe coding in ecpg

Andres Freund writes: > We could just refuse to support thread safety on mingw if that's not > supported? Or is that too aggressive? Nah, we already had that discussion upthread. Given the lack of prior complaints, we shouldn't break cases that are working today. For instance, as long as setloc

Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line

Hi Andrey, Thank you for the review! I have updated the patch according to your comments and remarks. Please, find new version attached. On 2019-01-07 12:12, Andrey Borodin wrote: Here are some my notes: 1. RestoreArchivedWAL() shares a lot of code with RestoreArchivedFile(). Is it possible\vi

Re: Protect syscache from bloating with negative cache entries

On Fri, Jan 18, 2019 at 05:09:41PM -0800, Andres Freund wrote: > Hi, > > On 2019-01-18 19:57:03 -0500, Robert Haas wrote: > > On Fri, Jan 18, 2019 at 4:23 PM and...@anarazel.de > > wrote: > > > My proposal for this was to attach a 'generation' to cache entries. Upon > > > access cache entries ar

Re: Alternative to \copy in psql modelled after \g

Bonsoir Daniel, sql> SELECT 1 \g /BAD /BAD: Permission denied sql> \echo :ERROR false That seems broken, because it's pointless to leave out a class of errors from ERROR. Yep. That is my point, but fixing it requires to decide whether it is okay to change ERROR documentation and

Re: Hint and detail punctuation

On Wed, Dec 5, 2018 at 05:22:25PM +0100, Daniel Gustafsson wrote: > While looking at error messages downstream, I noticed a few hints and details > in postgres which aren’t punctuated as per the style guide. The attached > patch > fixes the ones where it seemed reasonable to end with a period.

Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)

On Fri, Jan 18, 2019 at 4:06 PM Peter Geoghegan wrote: > > * Objects-to-drop output from DROP ROLE is still unstable. I suppose > > this would be fixed by also doing sorting in that code path, but > > I've not looked into it. > > The nbtree patch is not dependent on doing better here, since the >

Re: WIP: Avoid creation of the free space map for small tables

On Mon, Jan 21, 2019 at 6:32 AM Amit Kapila wrote: > So we won't allow transfer of FSM files if their size is below > HEAP_FSM_CREATION_THRESHOLD. What will be its behavior in link mode? > It seems that the old files will remain there. Will it create any > problem when we try to create the files

is there a reason we don't xlog index free space?

I knew that XLogRecordPageWithFreeSpace() is only called by heapam.c, but I figured indexes had their own logic to xlog free space. While investigating something else I found that brin indexes, at least, on the secondary have no FSMs. Is this deliberate? -- John Naylorhttps://www.

Re: COPY FROM WHEN condition

On 1/21/19 7:51 PM, Andres Freund wrote: > Hi, > > On 2019-01-21 16:22:11 +0100, Tomas Vondra wrote: >> >> >> On 1/21/19 4:33 AM, Tomas Vondra wrote: >>> >>> >>> On 1/21/19 3:12 AM, Andres Freund wrote: On 2019-01-20 18:08:05 -0800, Andres Freund wrote: > On 2019-01-20 21:00:21 -0500,

Re: should ConstraintRelationId ins/upd cause relcache invals?

On 2019-Jan-21, Tom Lane wrote: > Alvaro Herrera writes: > > At https://postgr.es/m/201901182216.nr5clsxrn624@alvherre.pgsql I posted > > a simplistic for the specific problem I found by calling > > CacheInvalidateRelcache in the problem spot. But I'm wondering if the > > correct fix isn't to h

Re: should ConstraintRelationId ins/upd cause relcache invals?

Hi, On 2019-01-21 19:40:17 -0300, Alvaro Herrera wrote: > On 2019-Jan-21, Tom Lane wrote: > > > Alvaro Herrera writes: > > > > At https://postgr.es/m/201901182216.nr5clsxrn624@alvherre.pgsql I posted > > > a simplistic for the specific problem I found by calling > > > CacheInvalidateRelcache in

RelationGetIndexAttrBitmap() small deviation between comment and code

(This is pretty minor, but I struggled to ignore it) In RelationGetIndexAttrBitmap() a comment claims /* We return our original working copy for caller to play with */. 3 of the 4 possible Bitmapsets follow that comment but for some reason, we make a copy of the primary key attrs before returning.

Re: Allowing extensions to find out the OIDs of their member objects

Hi, On 2019-01-20 18:50:33 -0500, Tom Lane wrote: > In [1] I propose that we should allow extensions to get their hands > on the ability to transform function calls as per "protransform" and > to generate lossy index quals based on items in WHERE clauses. The > APIs to give an extension control a

Re: problems with foreign keys on partitioned tables

Pushed now, thanks. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: should ConstraintRelationId ins/upd cause relcache invals?

Andres Freund writes: > Given > https://www.postgresql.org/message-id/20190121193300.gknn7p4pmmjg7nqf%40alap3.anarazel.de > and the concerns voiced in the thread quoted therein, I'm a bit > surprised that you just went ahead with this, and backpatched it to boot. I don't think that's relevant.

Re: Changing SQL Inlining Behaviour (or...?)

Hi, On 2019-01-19 20:53:55 -0500, Tom Lane wrote: > I wrote: > > Paul Ramsey writes: > >> Is there a rule of thumb we can use in costing our wrappers to ensure that > >> they always inline? > > > Not really, which is a weak spot of this whole approach. > > BTW, it suddenly strikes me that at

Re: Changing SQL Inlining Behaviour (or...?)

> On Jan 21, 2019, at 3:17 PM, Andres Freund wrote: > > Hi, > > On 2019-01-19 20:53:55 -0500, Tom Lane wrote: >> I wrote: >>> Paul Ramsey writes: Is there a rule of thumb we can use in costing our wrappers to ensure that they always inline? >> >>> Not really, which is a weak spot

Re: should ConstraintRelationId ins/upd cause relcache invals?

Hello On 2019-Jan-21, Andres Freund wrote: > On 2019-01-21 19:40:17 -0300, Alvaro Herrera wrote: > > On 2019-Jan-21, Tom Lane wrote: > > > > > Alvaro Herrera writes: > > > > > > At https://postgr.es/m/201901182216.nr5clsxrn624@alvherre.pgsql I posted > > > > a simplistic for the specific probl

Re: Changing SQL Inlining Behaviour (or...?)

Hi, On 2019-01-21 15:21:29 -0800, Paul Ramsey wrote: > As a practical matter, most of the exact-test functions have a > preamble that checks the bbox, so in the seqscan case having the > operator along for the ride isn’t any advantage. In any event, if we > do have exact tests w/o a lossy preamble

Re: RelationGetIndexAttrBitmap() small deviation between comment and code

David Rowley writes: > (This is pretty minor, but I struggled to ignore it) > In RelationGetIndexAttrBitmap() a comment claims /* We return our > original working copy for caller to play with */. 3 of the 4 possible > Bitmapsets follow that comment but for some reason, we make a copy of > the prim

Re: Changing SQL Inlining Behaviour (or...?)

> On Jan 21, 2019, at 3:27 PM, Andres Freund wrote: > > Hi, > > On 2019-01-21 15:21:29 -0800, Paul Ramsey wrote: >> As a practical matter, most of the exact-test functions have a >> preamble that checks the bbox, so in the seqscan case having the >> operator along for the ride isn’t any advan

Re: problems with foreign keys on partitioned tables

Hi Amit, Will you please rebase 0002? Please add your proposed tests cases to it, too. Thanks, -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: should ConstraintRelationId ins/upd cause relcache invals?

Hi, On 2019-01-21 18:14:31 -0500, Tom Lane wrote: > Andres Freund writes: > > Given > > https://www.postgresql.org/message-id/20190121193300.gknn7p4pmmjg7nqf%40alap3.anarazel.de > > and the concerns voiced in the thread quoted therein, I'm a bit > > surprised that you just went ahead with this,

Re: should ConstraintRelationId ins/upd cause relcache invals?

Andres Freund writes: > On 2019-01-21 18:14:31 -0500, Tom Lane wrote: >> I don't think that's relevant. The issues there were about whether >> a pg_index row update ought to cause an invalidation of the relcache >> entry for the index's table (not the one for the index, which it >> already takes

Re: should ConstraintRelationId ins/upd cause relcache invals?

Hi, On 2019-01-21 20:25:46 -0300, Alvaro Herrera wrote: > Hello > > On 2019-Jan-21, Andres Freund wrote: > > > On 2019-01-21 19:40:17 -0300, Alvaro Herrera wrote: > > > On 2019-Jan-21, Tom Lane wrote: > > > > > > > Alvaro Herrera writes: > > > > > > > > At https://postgr.es/m/201901182216.nr5

Re: PostgreSQL vs SQL/XML Standards

Hi, In two places in the XMLTABLE implementation (XmlTableFetchRow, iterating through a nodeset returned by the row_expression, and XmlTableGetValue, going through a nodeset returned by the column_expression), the iteration proceeds in index order through xpathobj->nodesetval->nodeTab. The same h

Re: Allowing extensions to find out the OIDs of their member objects

Andres Freund writes: > On 2019-01-20 18:50:33 -0500, Tom Lane wrote: >> In [1] I propose that we should allow extensions to get their hands >> on the ability to transform function calls as per "protransform" and >> to generate lossy index quals based on items in WHERE clauses. The >> APIs to giv

Re: RelationGetIndexAttrBitmap() small deviation between comment and code

On Tue, 22 Jan 2019 at 12:27, Tom Lane wrote: > > David Rowley writes: > > (This is pretty minor, but I struggled to ignore it) > > In RelationGetIndexAttrBitmap() a comment claims /* We return our > > original working copy for caller to play with */. 3 of the 4 possible > > Bitmapsets follow tha

Re: Allowing extensions to find out the OIDs of their member objects

Hi, On 2019-01-21 18:52:05 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2019-01-20 18:50:33 -0500, Tom Lane wrote: > >> In [1] I propose that we should allow extensions to get their hands > >> on the ability to transform function calls as per "protransform" and > >> to generate lossy ind

Re: Simplify set of flags used by MyXactFlags

On Mon, Jan 21, 2019 at 02:58:39PM -0300, Alvaro Herrera wrote: > "... operated on temp namespace" doesn't look good; seems to me to be > missing an article, for one thing, but really I'm not sure that > 'namespace' is the term to be using here. I'd say "... operated on > temporary objects" instea

Re: explain plans with information about (modified) gucs

On Sun, Jan 20, 2019 at 2:31 PM Tomas Vondra wrote: > Attached is v6 of the patch, adopting "settings" instead of "guc". Ok, looks good. I tried changing config values with the .conf file, alter system, and alter database, and tried a few queries with auto_explain. I made a pass through the confi

Re: Allowing extensions to find out the OIDs of their member objects

Andres Freund writes: > On 2019-01-21 18:52:05 -0500, Tom Lane wrote: >> Yes, I said in so many words that I was proposing increasing >> FirstNormalObjectId. I do not think the issues with pg_upgrade itself >> are insoluble --- it would need some historical knowledge about what >> FirstNormalObje

Re: Pluggable Storage - Andres's take

On Mon, Jan 21, 2019 at 1:01 PM Andres Freund wrote: > Hi, > > On 2018-12-10 18:13:40 -0800, Andres Freund wrote: > > On 2018-11-26 17:55:57 -0800, Andres Freund wrote: > > > FWIW, now that oids are removed, and the tuple table slot abstraction > > > got in, I'm working on rebasing the pluggable

Re: Pluggable Storage - Andres's take

Hi, Thanks! On 2019-01-22 11:51:57 +1100, Haribabu Kommi wrote: > Attached the patch for removal of scan_update_snapshot > and also the rebased patch of reduction in use of t_tableOid. I'll soon look at the latter. > > - consider removing table_gimmegimmeslot() > > - add substantial docs for e

Re: Allowing extensions to find out the OIDs of their member objects

> "Tom" == Tom Lane writes: Tom> I thought about extending the extension infrastructure to provide Tom> some way of retrieving relevant OIDs. We could imagine, for Tom> instance, that an extension script has a way to say "this function Tom> is object number three within this extension", a

Re: explain plans with information about (modified) gucs

On 1/22/19 1:35 AM, John Naylor wrote: > On Sun, Jan 20, 2019 at 2:31 PM Tomas Vondra > wrote: >> Attached is v6 of the patch, adopting "settings" instead of "guc". > > Ok, looks good. I tried changing config values with the .conf file, > alter system, and alter database, and tried a few queri

Re: Feature: temporary materialized views

On 1/21/19 3:31 AM, Andreas Karlsson wrote: Here is a a stab at refactoring this so the object creation does not happen in a callback. Rebased my patch on top of Andres's pluggable storage patches. Plus some minor style changes. Andreas diff --git a/src/backend/commands/createas.c b/src/back

Re: Allowing extensions to find out the OIDs of their member objects

Andrew Gierth writes: > "Tom" == Tom Lane writes: > Tom> I thought about extending the extension infrastructure to provide > Tom> some way of retrieving relevant OIDs. We could imagine, for > Tom> instance, that an extension script has a way to say "this function > Tom> is object number three

Re: Allowing extensions to find out the OIDs of their member objects

On 01/21/19 18:52, Tom Lane wrote: > I'm probably going to push forward with the OID mapping idea instead. As it happens, I'd been recently thinking[1] about a way that certain SQL/XML functionality could be provided by a pluggable selection of different extensions. And I think a use case like th

RE: speeding up planning with partitions

I measured the latency of queries executed before and after creating generic plan with master + v15-patch. In this test, table is partitioned into 4k partitions. I executed 400,0001 queries by pgbench. I changed the timing of creating generic plan at 1st, 10,001st, 20,001st, 50,001st, ..., 390,0

Re: Pluggable Storage - Andres's take

On Tue, Jan 22, 2019 at 12:15 PM Andres Freund wrote: > Hi, > > Thanks! > > On 2019-01-22 11:51:57 +1100, Haribabu Kommi wrote: > > Attached the patch for removal of scan_update_snapshot > > and also the rebased patch of reduction in use of t_tableOid. > > I'll soon look at the latter. > Thanks.

Re: Allowing extensions to find out the OIDs of their member objects

Chapman Flack writes: > On 01/21/19 18:52, Tom Lane wrote: >> I'm probably going to push forward with the OID mapping idea instead. > As it happens, I'd been recently thinking[1] about a way that certain > SQL/XML functionality could be provided by a pluggable selection of > different extensions.

  1   2   >