Re: How can we submit code patches that implement our (pending) patents?

2018-07-24 8:13 GMT+02:00 Tsunakawa, Takayuki < tsunakawa.ta...@jp.fujitsu.com>: > From: Bruce Momjian [mailto:br...@momjian.us] > > On Tue, Jul 10, 2018 at 08:20:53AM +, Tsunakawa, Takayuki wrote: > > > Yes, that's one unfortunate future, which I don't want to happen > > > of course. I

Re: FailedAssertion on partprune

On 24 July 2018 at 16:55, Jaime Casanova wrote: > I was trying sqlsmith on REL_11_STABLE (commit > 1b957e59b92dc44c14708762f882d7910463a9ac) with a database i have at > hand, and got an assertion failure. > It seems to happen during planning on prunning time but only when > tables get bigger than

Documenting that queries can be run over replication protocol

Hi; In the process of building some tooling based on replication we discovered that PostgreSQL 10 uses COPY to populate the initial table on logical replication, see commit 7c4f52409a8c7d85ed169bbbc1f6092274d03920 This is not currently documented. Attached is a patch which adds that

Re: Finding database for pg_upgrade missing library

> On 16 Jul 2018, at 14:13, Bruce Momjian wrote: > > On Sat, Jul 14, 2018 at 12:14:51AM +0200, Daniel Gustafsson wrote: >>> On 13 Jul 2018, at 18:28, Bruce Momjian wrote: >>> >>> I received a private pg_upgrade feature request to report the database >>> name for missing loadable libraries.

RE: How can we submit code patches that implement our (pending) patents?

From: Bruce Momjian [mailto:br...@momjian.us] > On Tue, Jul 10, 2018 at 08:20:53AM +, Tsunakawa, Takayuki wrote: > > Yes, that's one unfortunate future, which I don't want to happen > > of course. I believe PostgreSQL should accept patent for further > > evolution, because PostgreSQL is now a

Re: How can we submit code patches that implement our (pending) patents?

On Mon, Jul 23, 2018 at 8:12 PM, Joshua D. Drake wrote: > On 07/23/2018 12:06 PM, Bruce Momjian wrote: > >> So, is it FUD? The core needs paid-for legal advice, not speculation. >>> >>> I'm quite certain that a software license can make a patent grant to the >>> satisfaction of many open source

Re: [FEATURE PATCH] pg_stat_statements with plans (v02)

Hello I notice latest patch version (v06) not applied after da6f3e45ddb68ab3161076e120e7c32cfd46d1db commit in april. We have some consensus with design of this feature? I will mark CF entry as waiting on author regards, Sergei

Re: [HACKERS] Restricting maximum keep segments by repslots

On Mon, Jul 23, 2018 at 4:16 PM, Kyotaro HORIGUCHI wrote: > Hello. > > At Fri, 20 Jul 2018 10:13:58 +0900, Masahiko Sawada > wrote in >> > As I reconsidered this, I noticed that "lsn - lsn" doesn't make >> > sense here. The correct formula for the value is >> > "max_slot_wal_keep_size * 1024 *

Re: [HACKERS] Two pass CheckDeadlock in contentent case

On Mon, Jul 23, 2018 at 5:14 AM, Ashutosh Bapat wrote: > I think the case I am talking about is somewhere between these two - > the backend which has imprecisely decided that there's a deadlock will > start taking exclusive locks and will have to wait for all the > backends with shared locks to

Enhancement request: enable FIRST/LAST_value() also as a regular aggregate (not only as windowing function)

Hi All, I'd like to throw here an enhancement proposal to discuss/consider. The FIRST/LAST_value() functions offer powerful lookup capabilities, eg. here 1)

Re: Stored procedures and out parameters

David G. Johnston wrote: > > 2. A stored procedure can decide dynamically of > > the structure of the resultset(s) it returns, > > and the caller will discover it as they're returned, not > > before. > > > > The function itself doesn't care - this concern is about SELECT vs CALL >

Re: Stored procedures and out parameters

On Tue, Jul 24, 2018 at 11:31 AM, Daniel Verite wrote: > David G. Johnston wrote: > > > > 2. A stored procedure can decide dynamically of > > > the structure of the resultset(s) it returns, > > > and the caller will discover it as they're returned, not > > > before. > > > > > > > The

Re: BUG #15293: Stored Procedure Triggered by Logical Replication is Unable to use Notification Events

Hi Tom, Peter, On 2018-07-24 21:22:18 +0300, Sergei Kornilov wrote: > in fact, I've already tried to build fix. Adding ProcessCompletedNotifies to > apply_handle_commit fixed this issue and i think this is right place. In > src/backend/tcop/postgres.c we call ProcessCompletedNotifies similar

Re: BUG #15182: Canceling authentication due to timeout aka Denial of Service Attack

At Tue, 24 Jul 2018 14:23:02 +0900, Michael Paquier wrote in <20180724052302.gb4...@paquier.xyz> > On Mon, Jul 23, 2018 at 09:51:54PM -0700, Andres Freund wrote: > > On July 23, 2018 9:50:10 PM PDT, Michael Paquier > > wrote: > >> Oh, yes, that would be bad. My mind has slipped here. I have

Re: Have an encrypted pgpass file

Indeed having unencrypted password lying (.pgpass or PGPASSWORD or -W) around is making my auditors unhappy, and forcing me to enter the password over and over again. With a simple test it seems the password entered by the user also stays in memory, since it is able to reset a broken connection.

Re: Online enabling of checksums

The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: not tested Spec compliant: not tested Documentation:tested, failed Hello As i wrote few weeks ago i can not build documentation due

Re: [report] memory leaks in COPY FROM on partitioned table

Hi Kaigai-san, Thanks for the report and the patch. On 2018/07/24 11:43, Kohei KaiGai wrote: > Further investigation I did: > > CopyFrom() calls ExecFindPartition() to identify the destination child > table of partitioned table. > Then, it internally calls get_partition_for_tuple() to get

RE: Re: [Proposal] Add accumulated statistics for wait event

 2018-07-23 16:53 (GMT+9), Michael Paquier wrote: > On Mon, Jul 23, 2018 at 04:04:42PM +0900, 임명규 wrote: >> This proposal is about recording additional statistics of wait events. > I have comments about your patch. First, I don't think that you need to > count precisely the number of wait

Re: psql \df option for procedures

On 14.07.18 12:20, Peter Eisentraut wrote: > On 02.07.18 12:07, Peter Eisentraut wrote: >> psql's \df command current has options a/n/t/w to show >> aggregates/normal/trigger/window functions. Do we want to add something >> for procedures? > > Here is a patch. committed -- Peter Eisentraut

Re: Indicate anti-wraparound autovacuum in log_autovacuum_min_duration

On Tue, Jul 24, 2018 at 06:02:00PM +0900, Masahiko Sawada wrote: > Yeah, for translation I think it's better to make full lines. When we > added "aggressive" to autovacuum logs (commit b55509) we've done the > same thing. I am wondering if it would easier to add an extra line in the output, like

Re: [HACKERS] Optional message to user when terminating/cancelling backend

> On 6 Jul 2018, at 03:47, Michael Paquier wrote: > > On Fri, Jul 06, 2018 at 12:18:02PM +1200, Thomas Munro wrote: >> 6118 --select pg_cancel_backend(pg_backend_pid(), 'it brings on many >> changes'); >> 6119 select pg_cancel_backend(pg_backend_pid(), NULL); >> 6120! ERROR: canceling

Re: [HACKERS] Optional message to user when terminating/cancelling backend

> On 6 Jul 2018, at 02:18, Thomas Munro wrote: > > On Fri, Jun 15, 2018 at 9:56 AM, Daniel Gustafsson wrote: >> attached > > Hi Daniel, > > 6118 --select pg_cancel_backend(pg_backend_pid(), 'it brings on many > changes'); > 6119 select pg_cancel_backend(pg_backend_pid(), NULL); > 6120!

Re: Enhancement request: enable FIRST/LAST_value() also as a regular aggregate (not only as windowing function)

matshyeq writes: > I'd like to throw here an enhancement proposal to discuss/consider. > The FIRST/LAST_value() > functions offer powerful lookup capabilities, ... > but, given those values are repeating - why can't I simply use this > functions as regular aggregates? > Or can I? It doesn't seem

Re: BUG #15293: Stored Procedure Triggered by Logical Replication is Unable to use Notification Events

Andres Freund writes: > One other thing, somewhat independent, I wonder is if it's actually > problematic that we don't do ProcessCompletedNotifies() in a bunch of > processes, because that means we'll not necessarily call > asyncQueueAdvanceTail(). Perhaps that means we actually *do* need to do

Re: How can we submit code patches that implement our (pending) patents?

On 24 July 2018 at 18:17, Nico Williams wrote: > Note that it's OK to *accidentally* implement patented algorithms as > long as the author of the contribution didn't know about. There's no > trebble damages in that case, and no tainting of others, plus, > contributors and code

Re: Avoid extra Sort nodes between WindowAggs when sorting can be reused

> On 3 Jul 2018, at 12:24, Masahiko Sawada wrote: > Thank you for updating the patch. Thanks for reviewing! > Hmm, this is missing the eqop fields of SortGroupClause. I haven't > tested yet but does the similar degradation happen if two > SortGroupCaluses have different eqop and the same other

11beta crash/assert caused by parameter type changes

This crashes for me with an assert failure on latest 11-stable (and 12devel): create or replace function foo(text) returns text language plpgsql as $$ declare r record; t text; begin execute $1 into r; select pg_typeof(r.a) into t; -- dies on this one

Re: Enhancement request: enable FIRST/LAST_value() also as a regular aggregate (not only as windowing function)

I was hoping the proposal would be judged on its merits - primarily usefulness, not necessarily conforming to the standards I would expect postgres overlap with the SQL standard (eg. SQL:2016) doesn't differ much from other big vendors and has lots of own deviations/extensions itself. Not a fan of

Re: BUG #15293: Stored Procedure Triggered by Logical Replication is Unable to use Notification Events

Hi, On 2018-07-24 17:43:30 -0400, Tom Lane wrote: > Andres Freund writes: > > But I wonder if we shouldn't actually move the signalling part of > > ProcessCompletedNotifies() into CommitTransactionCommand() in v11. Given > > that transactions can now commit without a ready command being sent,

Re: BUG #15293: Stored Procedure Triggered by Logical Replication is Unable to use Notification Events

On 2018-07-24 18:01:33 -0400, Tom Lane wrote: > Andres Freund writes: > > One other thing, somewhat independent, I wonder is if it's actually > > problematic that we don't do ProcessCompletedNotifies() in a bunch of > > processes, because that means we'll not necessarily call > >

Early WIP/PoC for inlining CTEs

About a year ago I was briefly in discussion/collaboration with Adam Sah regarding the topic of inlining CTEs into the query rather than treating them as optimization barriers. We didn't take it very far (he sent me some stuff, I wrote some stuff and sent it back, things kind of got dropped at

Re: Early WIP/PoC for inlining CTEs

On Tue, Jul 24, 2018 at 5:28 PM Andrew Gierth wrote: > About a year ago I was briefly in discussion/collaboration with Adam Sah > regarding the topic of inlining CTEs into the query rather than treating > them as optimization barriers. We didn't take it very far (he sent me > some stuff, I wrote

Re: [HACKERS] Optional message to user when terminating/cancelling backend

> On 6 Jul 2018, at 14:12, Pavel Stehule wrote: > I am testing last patch and looks so truncating message and appending "..." > doesn't work. Thanks for testing, and sorry about the late response. > The slot->len hold trimmed length, not original length. Fixed in the attached rebased

Re: BUG #15293: Stored Procedure Triggered by Logical Replication is Unable to use Notification Events

Andres Freund writes: > But I wonder if we shouldn't actually move the signalling part of > ProcessCompletedNotifies() into CommitTransactionCommand() in v11. Given > that transactions can now commit without a ready command being sent, due > to the addition of procedures, that kind of seems

Re: How can we submit code patches that implement our (pending) patents?

On Tue, Jul 24, 2018 at 04:28:51PM +0100, Dave Page wrote: > On Tue, Jul 24, 2018 at 4:26 PM, Tomas Vondra > wrote: > > Clean room design addresses copyright-related issues, not patents. > > Correct. It's important folks realise that! Indeed. It's also important to know, when reading PG source

Re: Possible performance regression in version 10.1 with pgbench read-write tests.

On Mon, Jul 23, 2018 at 10:06 PM, Thomas Munro wrote: > Here's an attempt to use existing style better: a union, like > LWLockPadded and WALInsertLockPadded. I think we should back-patch to > 10. Thoughts? Pushed to 10, 11, master. It's interesting that I could see a further ~12% speedup by

Re: 11beta crash/assert caused by parameter type changes

On 24/07/18 22:50, Andrew Gierth wrote: > Haven't had time yet to poke at what's changed in detail. git bisect lays the blame on 6719b238e8f0ea83c39d2b1728c7670cdaa34e06. -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise,

Re: Early WIP/PoC for inlining CTEs

On 2018-07-24 18:03:43 -0500, Jeremy Finzel wrote: > On Tue, Jul 24, 2018 at 5:28 PM Andrew Gierth > wrote: > > > About a year ago I was briefly in discussion/collaboration with Adam Sah > > regarding the topic of inlining CTEs into the query rather than treating > > them as optimization

Re: Early WIP/PoC for inlining CTEs

> "Andres" == Andres Freund writes: Andres> Even in queries with a non-0 OFFSET you can push down in a Andres> number of cases, really? -- Andrew (irc:RhodiumToad)

RE: Locking B-tree leafs immediately in exclusive mode

On Mon, July 9, 2018 at 3:19 AM, Imai, Yoshikazu wrote: > I'm planning to do code review and send it in the next mail. Sorry for delaying the code review. I did the code review, and I think there are no logical wrongs with B-Tree. I tested integrity of B-Tree with amcheck just in case. I

Re: Early WIP/PoC for inlining CTEs

Andres Freund writes: > On 2018-07-24 18:03:43 -0500, Jeremy Finzel wrote: >> On Tue, Jul 24, 2018 at 5:28 PM Andrew Gierth >> wrote: >>> Posted for discussion, further development, criticism, whatever; feel >>> free to include this (with credit) in any relevant patch. Consider this >>> released

Re: Early WIP/PoC for inlining CTEs

Hi, On 2018-07-24 19:49:19 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2018-07-24 18:03:43 -0500, Jeremy Finzel wrote: > >> On Tue, Jul 24, 2018 at 5:28 PM Andrew Gierth > >> wrote: > >>> Posted for discussion, further development, criticism, whatever; feel > >>> free to include this

Re: [HACKERS] plpgsql - additional extra checks

On 07/22/2018 10:24 PM, Tomas Vondra wrote: > > > On 07/19/2018 02:50 PM, Pavel Stehule wrote: >> >> >> 2018-07-15 1:38 GMT+02:00 Tomas Vondra > >: >> >> Hi, >> >> I've been looking at the version submitted on Thursday, planning to >> commit it,

Re: Add SKIP LOCKED to VACUUM and ANALYZE

On Tue, Jul 24, 2018 at 05:21:25PM +, Bossart, Nathan wrote: > Here is a patch for refactoring the ereport() calls out of > vacuum_rel() and analyze_rel(). I've kept all four possible log > statements separated for ease of translation. I considered > simplifying these statements by replacing

Re: Early WIP/PoC for inlining CTEs

> "Andres" == Andres Freund writes: Andres> My read of the concensus (in which I am in the majority, so I Andres> might be biased) is that we do want inlining to be the default. Andres> We were thinking that it'd be necessary to provide a way to Andres> force inlining on the SQL level

Re: Early WIP/PoC for inlining CTEs

Andres Freund writes: > On 2018-07-24 19:49:19 -0400, Tom Lane wrote: >> However, a singly-referenced SELECT CTE could reasonably be treated as >> equivalent to a sub-select-in-FROM, and then you would have the same >> mechanisms for preventing inlining as you do for those cases, >> e.g. OFFSET

Re: Early WIP/PoC for inlining CTEs

Hi, On 2018-07-24 19:57:49 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2018-07-24 19:49:19 -0400, Tom Lane wrote: > >> However, a singly-referenced SELECT CTE could reasonably be treated as > >> equivalent to a sub-select-in-FROM, and then you would have the same > >> mechanisms for

Re: Early WIP/PoC for inlining CTEs

> "Tom" == Tom Lane writes: Tom> We can't inline wCTEs (those containing insert/update/delete) Tom> without risk of semantics change. Clearly. Tom> I'd also not favor changing the semantics for CTEs that are read Tom> more than once by the parent query. This one's more debatable.

Re: Early WIP/PoC for inlining CTEs

On 2018-07-25 01:08:44 +0100, Andrew Gierth wrote: > > "Andres" == Andres Freund writes: > > Andres> Even in queries with a non-0 OFFSET you can push down in a > Andres> number of cases, > > really? Yea. I guess it's a bit dependant on what kind of behaviour you consider as "pushing

Re: [HACKERS] plpgsql - additional extra checks

Committed, with some minor changes: > > 1) The too_many_rows check in exec_stmt_execsql included the errhint > conditionally, depending on force_error variable > > force_error = stmt->strict || stmt->mod_stmt; > use_errhint = !force_error; > > That is, the hint was not included when

Re: LLVM jit and matview

On Tue, Jul 24, 2018 at 07:49:56PM -0700, Andres Freund wrote: > FWIW, this doesn't crash for me, using a trunk checkout for LLVM. I'll > try older ones, as soon as they finish rebuilding. But perhaps you could > re-verify that this still is an issue on recent PG checkouts? And which > version of

Re: How can we submit code patches that implement our (pending) patents?

On Tue, Jul 24, 2018 at 06:29:37PM -0400, Isaac Morland wrote: > On 24 July 2018 at 18:17, Nico Williams wrote: > > Note that it's OK to *accidentally* implement patented algorithms as > > long as the author of the contribution didn't know about. There's no > > trebble damages in that case, and

Re: Stored procedures and out parameters

On Tue, Jul 24, 2018 at 6:58 AM, Daniel Verite wrote: > Vladimir Sitnikov wrote: > > > There's no notion if the called object is a procedure or function. > > Note: PostgreSQL can have a function that `returns void`, and it is hard > to > > tell if {call test()} refers to a function or

RE: [Proposal] Add accumulated statistics for wait event

Hi, > Some case, sampling of events can not find the cause of issue. It lose detail > data. > For example, some throughput issue occur(ex : disk io), but each wait point > occurs only a few milliseconds. It loses non meaningful details and it's in fact a good point. In this example,

Re: Stored procedures and out parameters

On Mon, Jul 23, 2018 at 12:07 PM, Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > 2) Just a side note: `CALL my_proc()` is not suitable for functions. That > looks weird. > Is the client expected to lookup system catalogs in order to tell if > `my_proc` is procedure or function and use

Re: Stored procedures and out parameters

Vladimir Sitnikov wrote: > There's no notion if the called object is a procedure or function. > Note: PostgreSQL can have a function that `returns void`, and it is hard to > tell if {call test()} refers to a function or procedure. > > Can functions and procedures be unified at the

Re: Indicate anti-wraparound autovacuum in log_autovacuum_min_duration

On Sat, Jul 21, 2018 at 6:26 PM, Sergei Kornilov wrote: > Hello > >> Yes, a bit more verbosity would be nice for that. Using the term >> "anti-wraparound" directly in the logs makes the most sense? > I used "(to prevent wraparound)" to looks like reporting in pg_stat_activity. > As far i can see

RE: Re: [Proposal] Add accumulated statistics for wait event

> On Mon, Jul 23, 2018 at 10:53 AM Michael Paquier wrote: >> What's the performance penalty? I am pretty sure that this is >> measurable as wait events are stored for a backend for each I/O >> operation as well, and you are calling a C routine within an inlined >> function which is designed

Re: Pluggable Storage - Andres's take

On Tue, Jul 17, 2018 at 11:01 PM Haribabu Kommi wrote: > > On Mon, Jul 16, 2018 at 11:35 PM Andres Freund wrote: > >> On 2018-07-04 20:11:21 +1000, Haribabu Kommi wrote: >> > On Tue, Jul 3, 2018 at 5:06 PM Andres Freund >> wrote: >> > >> > > - bitmap index scans probably need a new tableam.h

Re: FailedAssertion on partprune

David Rowley writes: > On 24 July 2018 at 16:55, Jaime Casanova > wrote: >> I was trying sqlsmith on REL_11_STABLE (commit >> 1b957e59b92dc44c14708762f882d7910463a9ac) with a database i have at >> hand, and got an assertion failure. > In this case, the 2nd to 5th Append subplan's parents are

Re: Have an encrypted pgpass file

Marco van Eck writes: > Indeed having unencrypted password lying (.pgpass or PGPASSWORD or -W) > around is making my auditors unhappy, and forcing me to enter the password > over and over again. With a simple test it seems the password entered by > the user also stays in memory, since it is able

Re: Expression errors with "FOR UPDATE" and postgres_fdw with partition wise join enabled.

(2018/07/24 3:09), Robert Haas wrote: On Mon, Jul 23, 2018 at 3:49 AM, Etsuro Fujita wrote: I have to admit that that is not a good idea. So, I'll update the patch so that we don't assume the projection capability of the subplan anymore, if we go this way. Isn't that assumption fundamental

RE: Re: [Proposal] Add accumulated statistics for wait event

Hi, I am skeptical about accumulated statistics. pg_stat_activity now gives necessary information about wait events. It can be easily be used with a polling system that sleeps most of the time to limit the overhead. Measuring the duration of individual wait events is not necessary to know the

Re: [WIP] [B-Tree] Retail IndexTuple deletion

On Sat, Jul 21, 2018 at 3:11 AM, Peter Geoghegan wrote: > On Thu, Jul 19, 2018 at 4:29 AM, Masahiko Sawada > wrote: >>> One area that might be worth investigating is retail index tuple >>> deletion performed within the executor in the event of non-HOT >>> updates. Maybe LP_REDIRECT could be

Summary of plans to avoid the annoyance of Freezing

* My vote is that we should try to get freeze maps into 9.6 - that seems * More realistic given that we have a patch right now. Yes, it might end * Up being superfluous churn, but it's rather localized. I think around *We’ve put off significant incremental improvements off with the promise *Of

Re: GSOC 2018 Project - A New Sorting Routine

On 07/24/2018 12:21 AM, Kefan Yang wrote: Hi Tomas! I did a few tests on my own Linux machine, but the problem is that my resources on AWS(CPU, RAM and even Disk space) are very limited. I considered establishing virtual machine on my own PC but the performance is even worse. My

Re: How can we submit code patches that implement our (pending) patents?

On 2018-Jul-24, Dave Page wrote: > tldr; it's a crap ton of work, risk and uncertainty for what might well be > zero benefit at the moment. Probably easiest way forward is to state the requirement and have someone untainted by the patent come up with a clean-room re-implementation. -- Álvaro

Re: [Proposal] Add accumulated statistics for wait event

On 07/24/2018 12:06 PM, MyungKyu LIM wrote:  2018-07-23 16:53 (GMT+9), Michael Paquier wrote: On Mon, Jul 23, 2018 at 04:04:42PM +0900, 임명규 wrote: This proposal is about recording additional statistics of wait events. I have comments about your patch. First, I don't think that you

Reviving the "Stopping logical replication protocol" patch from Vladimir Gordichuk

Back in 2016 a patch was proposed that seems to have died on the vine. See https://www.postgresql.org/message-id/flat/cafgjrd3hdyoa33m69tbeofnner2bzbwa8ffjt2v5vfztbvu...@mail.gmail.com for the history and https://commitfest.postgresql.org/10/621/ for the commitfest entry. I've rebased the

Re: How can we submit code patches that implement our (pending) patents?

On 07/24/2018 05:20 PM, Alvaro Herrera wrote: On 2018-Jul-24, Dave Page wrote: tldr; it's a crap ton of work, risk and uncertainty for what might well be zero benefit at the moment. Probably easiest way forward is to state the requirement and have someone untainted by the patent come up with

Re: How can we submit code patches that implement our (pending) patents?

On 07/24/2018 11:20 AM, Alvaro Herrera wrote: > Probably easiest way forward is to state the requirement and have > someone untainted by the patent come up with a clean-room > re-implementation. That sounds like an approach based on copyright considerations. A patent, on the other hand, will

Re: How can we submit code patches that implement our (pending) patents?

On Tue, Jul 24, 2018 at 4:26 PM, Tomas Vondra wrote: > On 07/24/2018 05:20 PM, Alvaro Herrera wrote: > >> On 2018-Jul-24, Dave Page wrote: >> >> tldr; it's a crap ton of work, risk and uncertainty for what might well be >>> zero benefit at the moment. >>> >> >> Probably easiest way forward is to

Re: Making "COPY partitioned_table FROM" faster

On Fri, Jul 20, 2018 at 7:57 AM, David Rowley wrote: > > So, overall, we feel that the code from lines 2689 until 2691 and from > 2740 to 2766 could use further clarification with regard to switching from > parent to child partition and sibling to sibling partition as well as > regarding saving

Re: [Proposal] Add accumulated statistics for wait event

On 07/23/2018 03:57 PM, Tom Lane wrote: Michael Paquier writes: This does not need a configure switch. It probably is there because the OP realizes that most people wouldn't accept having this code compiled in. What's the performance penalty? I am pretty sure that this is measurable as

Re: Making "COPY partitioned_table FROM" faster

On 24 July 2018 at 16:32, Melanie Plageman wrote: > > On Fri, Jul 20, 2018 at 7:57 AM, David Rowley > wrote: >> One final note: I'm not entirely convinced we need this adaptive >> code, but it seems easy enough to rip it back out if it's more trouble >> than it's worth. But if the other option

Re: Stored procedures and out parameters

>to compensate for the decisions made by the JDBC driver PostgreSQL It is not a decision by PostgreSQL JDBC driver. It is a decision by JDBC (Java Database Connectivity) specification itself. pgjdbc just follows the specification there. Well, there's an initiative for a new JDBC specification