Re: [HACKERS] Parallel execution and prepared statements

Amit Kapila wrote: > Can you once test by just passing CURSOR_OPT_PARALLEL_OK in > PrepareQuery() and run the tests by having forc_parallel_mode=regress? > It seems to me that the code in the planner is changed for setting a > parallelModeNeeded flag, so it might work as it is. No, that doesn't

Re: [HACKERS] Fun fact about autovacuum and orphan temp tables

On Thu, Nov 17, 2016 at 6:54 AM, Haribabu Kommi wrote: > you assigned as reviewer to the current patch in the 11-2016 commitfest. > But you haven't shared your review yet. Can you please try to share your > views > about the patch. This will help us in smoother operation

Re: [HACKERS] [RFC] Should we fix postmaster to avoid slow shutdown?

On 9/27/16 11:07 PM, Tsunakawa, Takayuki wrote: >> From: pgsql-hackers-ow...@postgresql.org >> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane >> Allowing SIGQUIT to prompt fast shutdown of the stats collector seems sane, >> though. Try to make sure it doesn't leave

Re: [HACKERS] Push down more full joins in postgres_fdw

Also another point I guess, this note doesn't add much value in the given context. Probably we should remove it. +* Note: the tlist would have one-to-one correspondence with the +* joining relation's reltarget->exprs because (1) the above test +* on PHVs

Re: [HACKERS] Mail thread references in commits

Tom Lane wrote: > AFAICS the proposal here is to go from, eg, > > Discussion: > > > to > > Discussion: > https://www.postgresql.org/message-id/caf4au4w6rrh_j1bvvhzposrihcog7sgj3lsx0ty8zdwhht8...@mail.gmail.com > > which is

Re: [HACKERS] patch: function xmltable

Hi 2016-11-17 19:22 GMT+01:00 Alvaro Herrera : > I've been going over this patch. I think it'd be better to restructure > the before adding the docs for this new function; I already > split it out, so don't do anything about this. > > Next, looking at struct

Re: [HACKERS] WIP: Covering + unique indexes.

On 10/4/16 10:47 AM, Anastasia Lubennikova wrote: > 03.10.2016 15:29, Anastasia Lubennikova: >> 03.10.2016 05:22, Michael Paquier: >>> On Tue, Sep 27, 2016 at 12:17 AM, Anastasia Lubennikova >>> wrote: Ok, I'll write it in a few days. >>> Marked as returned with

Re: [HACKERS] Mail thread references in commits

Robert Haas writes: > On Thu, Nov 17, 2016 at 10:43 PM, Joshua Drake wrote: >> Why not hash the URL? Something like: >> Http://postgresopen.org/archive/743257890976432 > I suggested that upthread... Don't like the hashing idea because that would

Re: [HACKERS] [RFC] Should we fix postmaster to avoid slow shutdown?

Tom Lane wrote: > Peter Eisentraut writes: > > On 11/14/16 4:38 AM, Ashutosh Bapat wrote: > >> The patch 02_close_listen... closes the listen sockets > >> explicitly when it's known that postmaster is going to stop all the > >> children and then die. I have tried

Re: [HACKERS] [RFC] Should we fix postmaster to avoid slow shutdown?

Robert Haas wrote: > On Fri, Nov 18, 2016 at 4:12 PM, Tom Lane wrote: > > Alvaro Herrera writes: > >> Tom Lane wrote: > >>> IMO it's not, and closer analysis says that this patch series is an > >>> attempt to solve something we already fixed, better,

Re: [HACKERS] Parallel execution and prepared statements

On Fri, Nov 18, 2016 at 8:21 AM, Albe Laurenz wrote: > I didn't notice the CREATE TABLE ... AS EXECUTE problem. > > But then the change to use CURSOR_OPT_PARALLEL_OK in tcop/postgres.c should > be reverted as well, because it breaks things just as bad: > >/* creates a

Re: [HACKERS] Mail thread references in commits

On Fri, Nov 18, 2016 at 11:08 PM, Alvaro Herrera wrote: > Tom Lane wrote: > > > AFAICS the proposal here is to go from, eg, > > > > Discussion: whht8...@mail.gmail.com> > > > > to > > > > Discussion: https://www.postgresql.org/message-id/CAF4Au4w6rrH_ >

Re: [HACKERS] Remove the comment on the countereffectiveness of large shared_buffers on Windows

On 11/17/16 12:30 AM, Tsunakawa, Takayuki wrote: > No, I'm not recommending a higher value, but just removing the doubtful > sentences of 512MB upper limit. The advantage is that eliminating this > sentence will make a chance for users to try best setting. I think this is a good point. The

Re: [HACKERS] Mail thread references in commits

On Thu, Nov 17, 2016 at 10:43 PM, Joshua Drake wrote: > Why not hash the URL? Something like: > > Http://postgresopen.org/archive/743257890976432 I suggested that upthread... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company --

Re: [HACKERS] Mail thread references in commits

Sorry didn't see it. On Nov 18, 2016 12:44, "Robert Haas" wrote: > On Thu, Nov 17, 2016 at 10:43 PM, Joshua Drake > wrote: > > Why not hash the URL? Something like: > > > > Http://postgresopen.org/archive/743257890976432 > > I suggested that

Re: [HACKERS] patch: function xmltable

Pavel Stehule wrote: > 2016-11-17 19:22 GMT+01:00 Alvaro Herrera : > > > Next, looking at struct TableExprBuilder I noticed that the comments are > > already obsolete, as they talk about function params that do not exist > > (missing_columns) and they fail to mention

Re: [HACKERS] [RFC] Should we fix postmaster to avoid slow shutdown?

On Fri, Nov 18, 2016 at 4:12 PM, Tom Lane wrote: > Alvaro Herrera writes: >> Tom Lane wrote: >>> IMO it's not, and closer analysis says that this patch series is an >>> attempt to solve something we already fixed, better, in 9.4. > >> ... by the same

Re: [HACKERS] Fun fact about autovacuum and orphan temp tables

On Thu, Nov 17, 2016 at 4:25 PM, Michael Paquier wrote: > On Thu, Nov 17, 2016 at 11:16 AM, Robert Haas wrote: >> On Thu, Nov 17, 2016 at 1:41 PM, Michael Paquier >> wrote: >>> Okay, let's remove the documentation

Re: [HACKERS] [RFC] Should we fix postmaster to avoid slow shutdown?

Alvaro Herrera writes: > Tom Lane wrote: >> IMO it's not, and closer analysis says that this patch series is an >> attempt to solve something we already fixed, better, in 9.4. > ... by the same patch submitter. [ confused ] The commit log credits 82233ce7e to MauMau

Re: [HACKERS] [RFC] Should we fix postmaster to avoid slow shutdown?

Alvaro Herrera writes: > Robert Haas wrote: >> IIUC, MauMau = Tsunakawa Takayuki. > Right, > https://www.postgresql.org/message-id/964413269E3A41409EA53EE0D813E48C@tunaPC Ah! I'd forgotten. regards, tom lane -- Sent via pgsql-hackers

Re: [HACKERS] [RFC] Should we fix postmaster to avoid slow shutdown?

Peter Eisentraut writes: > On 11/14/16 4:38 AM, Ashutosh Bapat wrote: >> The patch 02_close_listen... closes the listen sockets >> explicitly when it's known that postmaster is going to stop all the >> children and then die. I have tried to see, if there's a

Re: [HACKERS] Declarative partitioning - another take

On Fri, Nov 18, 2016 at 5:59 AM, Amit Langote wrote: > Oh but wait, that means I can insert rows with NULLs in the range > partition key if I choose to insert it directly into the partition, > whereas I have been thinking all this while that there could never be >

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Thu, Nov 17, 2016 at 10:08 PM, Craig Ringer wrote: > On 17 November 2016 at 10:57, Robert Haas wrote: >> On Wed, Nov 16, 2016 at 9:00 PM, Tsunakawa, Takayuki >> wrote: >>> Do we really want to enable libpq failover

Re: [HACKERS] Snapshot too old logging

On Wed, Nov 16, 2016 at 6:43 AM, Robert Haas wrote: > I think I was suggesting: One or more rows required by this query may > already have been removed from "%s". I keep reading that as "you have data corruption because something removed rows that your query needs" rather than "this query took

Re: [HACKERS] [RFC] Should we fix postmaster to avoid slow shutdown?

On 11/14/16 4:38 AM, Ashutosh Bapat wrote: > The patch 02_close_listen... closes the listen sockets > explicitly when it's known that postmaster is going to stop all the > children and then die. I have tried to see, if there's a possibility > that it closes the listen sockets but do not actually

Re: [HACKERS] [RFC] Should we fix postmaster to avoid slow shutdown?

I wrote: > Peter Eisentraut writes: >> ISTM that this would change the "immediate shutdown" to not save stats >> files anymore. So far, all the shutdown modes are equivalent in terms >> of how they preserve data and system state. They differ only in when >> the

Re: [HACKERS] [RFC] Should we fix postmaster to avoid slow shutdown?

On 11/18/16 12:00 PM, Tom Lane wrote: > My feeling is that 82233ce7e has obsoleted all of the proposals made so > far in this thread, and that we should reject them all. Yes, it seems that very similar concerns were already addressed there. -- Peter Eisentraut

Re: [HACKERS] Declarative partitioning - another take

On Thu, Nov 17, 2016 at 8:18 PM, Amit Langote wrote: > The reason NULLs in an input row are caught and rejected (with the current > message) before control reaches range_partition_for_tuple() is because > it's not clear to me whether the range bound comparison logic

Re: [HACKERS] Unlogged tables cleanup

On Thu, Nov 17, 2016 at 7:06 AM, Robert Haas wrote: > Yeah, but surely it's obvious that if you don't WAL log it, it's not > going to work for archiving or streaming. It's a lot less obvious why > you have to WAL log it when you're not doing either of those things if >

Re: [HACKERS] Snapshot too old logging

On Fri, Nov 18, 2016 at 11:49 AM, Brad DeJong wrote: > On Wed, Nov 16, 2016 at 6:43 AM, Robert Haas wrote: >> I think I was suggesting: One or more rows required by this query may >> already have been removed from "%s". > > I keep reading that as "you have data corruption

Re: [HACKERS] Fix checkpoint skip logic on idle systems by tracking LSN progress

On 11/14/16 4:29 AM, Michael Paquier wrote: > On Mon, Nov 14, 2016 at 6:10 PM, Kyotaro HORIGUCHI > wrote: >> It applies the master and compiled cleanly and no error by >> regtest. (I didn't confirmed that the problem is still fixed but >> seemingly no problem) >

Re: [HACKERS] [RFC] Should we fix postmaster to avoid slow shutdown?

Peter Eisentraut writes: > ISTM that this would change the "immediate shutdown" to not save stats > files anymore. So far, all the shutdown modes are equivalent in terms > of how they preserve data and system state. They differ only in when > the hard work

Re: [HACKERS] WAL recycle retading based on active sync rep.

Hi, On 2016-11-18 14:12:42 +0900, Kyotaro HORIGUCHI wrote: > We had too-early WAL recycling during a test we had on a sync > replication set. This is not a bug and a bit extreme case but is > contrary to expectation on synchronous replication. I don't think you can expect anything else. > This

Re: [HACKERS] JIT compiler for expressions

On 10/28/16 6:47 AM, Dmitry Melnik wrote: We'd like to present our work on adding LLVM JIT compilation of expressions in SQL queries for PostgreSQL. The source code (based on 9.6.1) along with brief manual is available at our github: https://github.com/ispras/postgres

Re: [HACKERS] pg_sequence catalog

On 11/11/16 12:53 PM, Andreas Karlsson wrote: > Other than my comment above about is_called and last_value I think the > patch looks great. I have made that change and committed the patch. Thanks. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7

Re: [HACKERS] Tuple count used while costing MergeAppend and that for an append rel

Ashutosh Bapat writes: > AFAIU, There's difference in the tuples and rows members of > RelOptInfo. While tuples gives the estimate of number of tuples per > pg_class, rows gives the number of rows output by that relation. From > that perspective rel->tuples should

Re: [HACKERS] patch: function xmltable

The SQL standard seems to require a comma after the XMLNAMESPACES clause: ::= XMLTABLE [ ] [ ] COLUMNS I don't understand the reason for that, but I have added it: | XMLTABLE '(' XMLNAMESPACES '(' XmlNamespaceList ')' ',' c_expr xmlexists_argument

Re: [HACKERS] Mail thread references in commits

On 11/18/16 4:35 PM, Magnus Hagander wrote: Another option would be to teach the URL shortener about our messages specifically, and just use an internal surrogate key we already have for them. That way it could be something like the current Planet URLs (which can be for example

Re: [HACKERS] [WIP] [B-Tree] Keep indexes sorted by heap physical location

On Thu, Aug 18, 2016 at 2:15 PM, Peter Geoghegan wrote: > I think that this is a bad idea. We need to implement suffix > truncation of internal page index tuples at some point, to make them > contain less information from the original leaf page index tuple. > That's an important

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On 19 November 2016 at 01:29, Robert Haas wrote: >> We can and probably should have both. >> >> If the server tells us on connect whether it's a standby or not, use that. >> >> Otherwise, ask it. >> >> That way we don't pay the round-trip cost and get the log spam when >>

Re: [HACKERS] Mail thread references in commits

On November 18, 2016 1:06:18 PM PST, Tom Lane wrote: >Robert Haas writes: >> On Thu, Nov 17, 2016 at 10:43 PM, Joshua Drake >wrote: >>> Why not hash the URL? Something like: >>> Http://postgresopen.org/archive/743257890976432

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On Thu, Nov 17, 2016 at 12:04 PM, Peter Geoghegan wrote: >> Hm, if we want that - and it doesn't seem like a bad idea - I think we >> should be make it available without recompiling. > > I suppose, provided it doesn't let CORRUPTION elevel be < ERROR. That > might be broken if it

Re: [HACKERS] pg_recvlogical --endpos

On 01-09-2016 01:41, Craig Ringer wrote: > Here's a rebased version of my pg_recvlogical --endpos patch from the > 9.5 series, updated to incoroprate Álvaro's changes. > I should review this patch in the other commitfest but was swamped with work. The patch is almost ready but I have some points.

Re: [HACKERS] Mail thread references in commits

Magnus, * Magnus Hagander (mag...@hagander.net) wrote: > It would make the URLs actually short, but as mentioned upthread, that > wouldn't work at all if offline. So it'd be a tradeoff between those, but > so are pretty much all other options that don't include the full message-id. This is a bit

Re: [HACKERS] Mail thread references in commits

On 11/18/2016 07:07 PM, Stephen Frost wrote: Magnus, * Magnus Hagander (mag...@hagander.net) wrote: It would make the URLs actually short, but as mentioned upthread, that wouldn't work at all if offline. So it'd be a tradeoff between those, but so are pretty much all other options that don't

Re: [HACKERS] [WIP] [B-Tree] Keep indexes sorted by heap physical location

On Fri, Nov 18, 2016 at 10:05 PM, Peter Geoghegan wrote: > On Thu, Aug 18, 2016 at 2:15 PM, Peter Geoghegan wrote: >> I think that this is a bad idea. We need to implement suffix >> truncation of internal page index tuples at some point, to make them >> contain

Re: [HACKERS] [WIP] [B-Tree] Keep indexes sorted by heap physical location

On Fri, Nov 18, 2016 at 5:27 PM, Claudio Freire wrote: > I've been changing the on-disk format considerably, to one that makes > more sense. I can see how that would be necessary. I'm going to suggest some more things that need a new btree version number now, too. I

Re: [HACKERS] Mail thread references in commits

On Fri, Nov 18, 2016 at 6:05 PM, Andres Freund wrote: > I do ask of that offline or at least locally. So I won't use something that > makes that uncomfortable. No committer here. But I do search for mails using the discussion ID present in the log message by querying in my

Re: [HACKERS] patch: function xmltable

2016-11-19 5:19 GMT+01:00 Pavel Stehule : > > > 2016-11-19 0:42 GMT+01:00 Alvaro Herrera : > >> The SQL standard seems to require a comma after the XMLNAMESPACES >> clause: >> >> ::= >> XMLTABLE >> [ ] >> >> [ ] >> COLUMNS

Re: [HACKERS] possible optimizations - pushing filter before aggregation

2016-11-19 3:59 GMT+01:00 Douglas Doole : > > On Fri, Nov 18, 2016 at 12:47 AM Pavel Stehule > wrote: > > Isn't possible in this case push equivalence before aggregation? > > > If I'm understanding you correctly, that would lead to wrong results. >

Re: [HACKERS] patch: function xmltable

2016-11-19 0:42 GMT+01:00 Alvaro Herrera : > The SQL standard seems to require a comma after the XMLNAMESPACES > clause: > > ::= > XMLTABLE > [ ] > > [ ] > COLUMNS > > I don't understand the reason for that, but I have added it: > >

Re: [HACKERS] Fix checkpoint skip logic on idle systems by tracking LSN progress

On Fri, Nov 18, 2016 at 7:00 PM, Amit Kapila wrote: > Okay, I have done some performance tests with this patch and found that it > doesn't have any noticeable impact which is good. Details of performance > tests is below: > Machine configuration: > 2 sockets, 28 cores

Re: [HACKERS] Re: [bug fix] Cascading standby cannot catch up and get stuck emitting the same message repeatedly

On Mon, Sep 5, 2016 at 8:42 AM, Tsunakawa, Takayuki wrote: > > From: pgsql-hackers-ow...@postgresql.org > > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tsunakawa, > > Our customer hit a problem of cascading replication, and we found the cause. > > They

[HACKERS] How to change order sort of table in HashJoin

Hi Experts, As in the example below, i think the plan which hash table is created on testtbl2 (the fewer tuples) should be choosen. Because creating of hash table should faster in testtbl2. But it did not. I have tried to change the ordering of table by tuning parameter even if using

Re: [HACKERS] Fix checkpoint skip logic on idle systems by tracking LSN progress

On Mon, Nov 14, 2016 at 9:33 AM, Michael Paquier wrote: > On Mon, Nov 14, 2016 at 12:49 PM, Kyotaro HORIGUCHI > wrote: >> At Sat, 12 Nov 2016 10:28:56 +0530, Amit Kapila wrote in

Re: [HACKERS] possible optimizations - pushing filter before aggregation

On Fri, Nov 18, 2016 at 12:47 AM Pavel Stehule wrote: Isn't possible in this case push equivalence before aggregation? If I'm understanding you correctly, that would lead to wrong results. Here's a simple example: CREATE VIEW v AS SELECT MIN(a) m FROM t; and table T

Re: [HACKERS] Mail thread references in commits

On 11/18/2016 09:05 PM, Andres Freund wrote: On November 18, 2016 1:06:18 PM PST, Tom Lane wrote: I think it's important to have the message-ID in cleartext. I do ask of that offline or at least locally. So I won't use something that makes that uncomfortable. I

Re: [HACKERS] Fun fact about autovacuum and orphan temp tables

On Fri, Nov 18, 2016 at 1:11 PM, Robert Haas wrote: > So now I think that we probably need to make this logic a bit smarter. > Add all of the OIDs that need to be dropped to a list. Then have a > loop prior to the main loop (where it says "Perform operations on > collected

Re: [HACKERS] Performance degradation in Bitmapscan (commit 75ae538bc3168bf44475240d4e0487ee2f3bb376)

On Tue, Nov 15, 2016 at 2:28 PM, Andres Freund wrote: > I've a working fix for this, and for a similar issue Robert found. I'm > still playing around with it, but basically the fix is to make the > growth policy a bit more adaptive. Any chance you can post a patch soon? --

Re: [HACKERS] Parallel execution and prepared statements

Robert Haas wrote: > On Tue, Nov 15, 2016 at 10:41 AM, Albe Laurenz > wrote: >> Tobias Bussmann has discovered an oddity with prepared statements. >> >> Parallel scan is used with prepared statements, but only if they have >> been created with protocol V3 "Parse". >> If

Re: [HACKERS] Push down more full joins in postgres_fdw

> > /* > * For a join relation or an upper relation, use > deparseExplicitTargetList. > * Likewise, for a base relation that is being deparsed as a subquery, > in > * which case the caller would have passed tlist that is non-NIL, use > that > * function. Otherwise, use

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

On 18 November 2016 at 14:04, Tsunakawa, Takayuki wrote: > Hello, Craig, > > I'm sorry to be late to review your patch. I've just been able to read the > HTML doc first. Can I get the latest .patch file for reading and running the > code? The latest is what's

Re: [HACKERS] Contains and is contained by operators of inet datatypes

> The new names might be better if we were starting in a green field, > but in themselves they are not any more mnemonic than what we had, and > what we had has been there for a lot of years. Also, if we accept both > old names and new (which it seems like we'd have to), that creates new >

Re: [HACKERS] Hash Indexes

On Fri, Nov 18, 2016 at 12:11 PM, Amit Kapila wrote: > On Thu, Nov 17, 2016 at 10:54 PM, Robert Haas wrote: >> On Thu, Nov 17, 2016 at 12:05 PM, Amit Kapila >> wrote: >> I think this comment is saying that we'll

[HACKERS] Tuple count used while costing MergeAppend and that for an append rel

Hi, In create_merge_append_path() we have following code 1331 1332 /* Now we can compute total costs of the MergeAppend */ 1333 cost_merge_append(>path, root, 1334 pathkeys, list_length(subpaths), 1335 input_startup_cost, input_total_cost, 1336

[HACKERS] possible optimizations - pushing filter before aggregation

Hi In one application I see slow queries. There is often used views like CREATE VIEW v AS SELECT min(a) M1, min(b) M2, max(c) M3, x, y, z FROM t1 GROUP BY x, y, z; and queries like SELECT * FROM v WHERE M2 = const1 AND M3 > const2 Isn't possible in this case push equivalence

Re: [HACKERS] WAL recycle retading based on active sync rep.

On 18 Nov. 2016 13:14, "Kyotaro HORIGUCHI" wrote: > > Hello. > > We had too-early WAL recycling during a test we had on a sync > replication set. This is not a bug and a bit extreme case but is > contrary to expectation on synchronous replication. Isn't this

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

> To keep such kind of integrity, we should deeply consider about > errors. My point is that I don't think we can keep integrity together with the fuzzy behaviour, or at least I don't have the skills to do that. I can just leave the more complicated operators like "is a point on a line" as it

Re: [HACKERS] Mail thread references in commits

On Fri, Nov 18, 2016 at 1:38 AM, Alvaro Herrera wrote: > Tom Lane wrote: >> Andrew Dunstan writes: >> > I love seeing references to email threads in commit messages. It would >> > make them a lot friendlier though if a full http URL were included >>