Re: [HACKERS] Measuring replay lag

On Fri, Feb 17, 2017 at 12:45 AM, Simon Riggs wrote: > Feeling happier about this for now at least. Thanks! > I think we need to document how this works more in README or header > comments. That way I can review it against what it aims to do rather > than what I think it

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/02/16 23:40, Robert Haas wrote: > On Thu, Feb 16, 2017 at 6:32 AM, Simon Riggs wrote: >> Why not vacuum all partitions? >> Why not analyze all partitions? >> Truncate all partitions > > I agree. But, we need to be careful that a database-wide VACUUM or > ANALYZE

Re: [HACKERS] Measuring replay lag

On Thu, Feb 16, 2017 at 11:18 PM, Abhijit Menon-Sen wrote: > Hi Thomas. > > At 2017-02-15 00:48:41 +1300, thomas.mu...@enterprisedb.com wrote: >> >> Here is a new version with the buffer on the sender side as requested. > > This looks good. Thanks for the review! >> +

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Thu, Feb 16, 2017 at 8:16 PM, Amit Kapila wrote: > On Thu, Feb 16, 2017 at 7:15 AM, Robert Haas wrote: > > Attached are refactoring patches. WAL patch needs some changes based > on above comments, so will post it later. > Attached is a rebased

Re: ParallelFinish-hook of FDW/CSP (Re: [HACKERS] Steps inside ExecEndGather)

Hello, The attached patch is revised one. Invocation of Exec(Foreign|Custom)ParallelFinish was moved to ExecParallelRetrieveInstrumentation() not to walk on the plan- state tree twice. One (hypothetical) downside is, FDW/CSP can retrieve its own run-time statistics only when query is executed

Re: [HACKERS] Partitioning vs ON CONFLICT

On 2017/02/17 14:50, Peter Geoghegan wrote: > On Thu, Feb 16, 2017 at 9:27 PM, Amit Langote > wrote: >> Attached patch fixes that. Thom, your example query should not error out >> with the patch. As discussed here, DO UPDATE cannot be supported at the >> moment. >

[HACKERS] pg_recvlogical.c doesn't build with --disable-integer-datetimes

Hi, Since commit 7c030783a5bd07cadffc2a1018bc33119a4c7505 it seems that $SUBJECT. pg_recvlogical.c:501:37: error: incompatible pointer types passing 'int64 *' (aka 'long *') to parameter of type 'TimestampTz *' (aka 'double *') [-Werror,-Wincompatible-pointer-types]

Re: [HACKERS] Parallel Append implementation

On Thu, Feb 16, 2017 at 8:15 PM, Robert Haas wrote: > On Wed, Feb 15, 2017 at 11:15 PM, Ashutosh Bapat > wrote: >> If the user is ready throw 200 workers and if the subplans can use >> them to speed up the query 200 times (obviously I am

Re: [HACKERS] Documentation improvements for partitioning

Forgot to attach the patch. Thanks Rajkumar for notifying me. On Fri, Feb 17, 2017 at 11:18 AM, Ashutosh Bapat wrote: > In the documentation of ALTER TABLE ... ATTACH PARTITION its implicit > that partition name specified should be the name of the existing table

[HACKERS] Instability in select_parallel regression test

Buildfarm members gaur, pademelon, and gharial have all recently shown failures like this: *** /home/bfarm/bf-data/HEAD/pgsql.build/src/test/regress/expected/select_parallel.out Thu Feb 16 20:35:14 2017 --- /home/bfarm/bf-data/HEAD/pgsql.build/src/test/regress/results/select_parallel.out

Re: [HACKERS] Partitioning vs ON CONFLICT

On Thu, Feb 16, 2017 at 9:27 PM, Amit Langote wrote: > Attached patch fixes that. Thom, your example query should not error out > with the patch. As discussed here, DO UPDATE cannot be supported at the > moment. Maybe you should just let infer_arbiter_indexes()

Re: [HACKERS] Documentation improvements for partitioning

In the documentation of ALTER TABLE ... ATTACH PARTITION its implicit that partition name specified should be the name of the existing table being attached. Same is the case with DETACH PARTITION where its implicit that the detached partition becomes a stand-alone table with same name as the

Re: [HACKERS] Partitioning vs ON CONFLICT

On 2017/02/17 13:25, Peter Geoghegan wrote: > On Thu, Feb 16, 2017 at 8:21 PM, Amit Langote > wrote: >> would be working on a leaf partition chosen by tuple-routing after an >> insert on a partitioned table. The leaf partitions can very well have a >> unique index,

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

On 22 November 2016 at 18:32, Craig Ringer wrote: > On 22 November 2016 at 15:14, Haribabu Kommi > wrote: > > > > On Fri, Nov 18, 2016 at 7:18 PM, Craig Ringer > wrote: > >> > >> The latest is what's attached upthread and

Re: [HACKERS] Parallel Index-only scan

On Thu, Feb 16, 2017 at 9:25 PM, Amit Kapila wrote: > > Few comments: > > 1. > + * ioss_PscanLen This is needed for parallel index scan > * > */ > typedef struct IndexOnlyScanState > @@ -1427,6 +1428,7 @@ typedef struct IndexOnlyScanState >

Re: [HACKERS] Partitioning vs ON CONFLICT

On Thu, Feb 16, 2017 at 8:21 PM, Amit Langote wrote: > would be working on a leaf partition chosen by tuple-routing after an > insert on a partitioned table. The leaf partitions can very well have a > unique index, which can be used for inference. The problem

Re: [HACKERS] Partitioning vs ON CONFLICT

On 2017/02/17 1:17, Peter Geoghegan wrote: > But surely it should be possible to use DO NOTHING without inferring some > particular unique index? That's possible with an approach based on > inheritance. Hmm. Code after the following comment fragment in ExecInsert(): * Do a

Re: [HACKERS] Implement custom join algorithm

Amin Fallahi writes: > I want to implement my custom join algorithm into postgres. Where should I > start? Where in the code base and how the current algorithms are currently > implemented? TBH, if this is your first Postgres programming project, you might want to set

Re: [HACKERS] SUBSCRIPTIONS and pg_upgrade

Peter, * Stephen Frost (sfr...@snowman.net) wrote: > * Peter Eisentraut (pete...@gmx.net) wrote: > > Logical replication > > > > - Add PUBLICATION catalogs and DDL > > - Add SUBSCRIPTION catalog and DDL > > - Define logical replication protocol and output plugin > > - Add logical replication

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/02/15 16:14, Michael Paquier wrote: > On Fri, Feb 10, 2017 at 3:19 PM, Amit Langote > wrote: >> The new partitioned tables do not contain any data by themselves. Any >> data inserted into a partitioned table is routed to and stored in one of >> its

[HACKERS] SUBSCRIPTIONS and pg_upgrade

Peter, * Peter Eisentraut (pete...@gmx.net) wrote: > Logical replication > > - Add PUBLICATION catalogs and DDL > - Add SUBSCRIPTION catalog and DDL > - Define logical replication protocol and output plugin > - Add logical replication workers I'm not entirely sure about the reasoning behind

Re: [HACKERS] Avoiding OOM in a hash join with many duplicate inner keys

On Fri, Feb 17, 2017 at 11:13 AM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Feb 16, 2017 at 3:51 PM, Tom Lane wrote: >>> No, it'd be the *most* common MCV, because we're concerned about the >>> worst-case (largest) bucket

[HACKERS] Implement custom join algorithm

Hi I want to implement my custom join algorithm into postgres. Where should I start? Where in the code base and how the current algorithms are currently implemented?

Re: [HACKERS] Avoiding OOM in a hash join with many duplicate inner keys

Robert Haas writes: > On Thu, Feb 16, 2017 at 3:51 PM, Tom Lane wrote: >> No, it'd be the *most* common MCV, because we're concerned about the >> worst-case (largest) bucket size. But that's good, really, because the >> highest MCV frequency will be

[HACKERS] [PATCH] Add pg_disable_checksums() and supporting infrastructure

Extracted from a larger patch, this patch provides the basic infrastructure for turning data checksums off in a cluster. This also sets up the necessary pg_control fields to support the necessary multiple states for handling the transitions. We do a few things: - Change "data_checksums" from

Re: [HACKERS] Avoiding OOM in a hash join with many duplicate inner keys

On Thu, Feb 16, 2017 at 3:51 PM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Feb 16, 2017 at 2:38 PM, Tom Lane wrote: >>> I initially thought about driving the shutoff strictly from the estimate >>> of the MCV frequency,

Re: [HACKERS] Avoiding OOM in a hash join with many duplicate inner keys

Robert Haas writes: > On Thu, Feb 16, 2017 at 2:38 PM, Tom Lane wrote: >> I initially thought about driving the shutoff strictly from the estimate >> of the MCV frequency, without involving the more general ndistinct >> computation that

Re: [HACKERS] Small issue in online devel documentation build

My point is that some xsl file should be fixed somewhere, probably, to avoid that. Yeah, I noticed this too, and I think Ashutosh also complained about it on another thread. It's pretty annoying - I hope somebody can figure out the cause and fix it. It seems to be only affecting the

Re: [HACKERS] Parallel bitmap heap scan

On Thu, Feb 16, 2017 at 10:54 AM, Dilip Kumar wrote: > interface_dsa_allocate0.patch : Provides new interface dsa_allocate0, > which is used by 0001 Committed. I moved the function prototype for dsa_allocate0() next to the existing prototype for dsa_allocate(). Please

Re: [HACKERS] Avoiding OOM in a hash join with many duplicate inner keys

On Thu, Feb 16, 2017 at 2:38 PM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Feb 16, 2017 at 2:02 PM, Tom Lane wrote: >>> This might be overly aggressive, because it will pretty much shut off >>> any attempt to use hash joining

Re: [HACKERS] Avoiding OOM in a hash join with many duplicate inner keys

Robert Haas writes: > On Thu, Feb 16, 2017 at 2:02 PM, Tom Lane wrote: >> This might be overly aggressive, because it will pretty much shut off >> any attempt to use hash joining on a large inner relation unless we >> have statistics for it (and those

Re: [HACKERS] Avoiding OOM in a hash join with many duplicate inner keys

On Thu, Feb 16, 2017 at 11:11 AM, Robert Haas wrote: > I do think that's worrying, but on the other hand it seems like this > solution could disable many hash joins that would actually be fine. I > don't think the largest ndistinct estimates we ever generate are very >

Re: [HACKERS] Avoiding OOM in a hash join with many duplicate inner keys

On Thu, Feb 16, 2017 at 2:02 PM, Tom Lane wrote: > The planner doesn't currently worry about work_mem restrictions when > planning a hash join, figuring that the executor should be able to > subdivide the data arbitrarily finely by splitting buckets at runtime. > However

[HACKERS] Avoiding OOM in a hash join with many duplicate inner keys

The planner doesn't currently worry about work_mem restrictions when planning a hash join, figuring that the executor should be able to subdivide the data arbitrarily finely by splitting buckets at runtime. However there's a thread here:

Re: [HACKERS] COPY IN/BOTH vs. extended query mode

On Mon, Feb 13, 2017 at 4:29 PM, Craig Ringer wrote: > > > On 14 Feb. 2017 06:15, "Robert Haas" wrote: > > On Mon, Jan 23, 2017 at 9:12 PM, Robert Haas > wrote: > > According to the documentation for COPY IN mode, "If

Re: [HACKERS] GUC for cleanup indexes threshold.

On Thu, Feb 16, 2017 at 6:17 AM, Simon Riggs wrote: > On 15 February 2017 at 08:07, Masahiko Sawada wrote: >> It's a bug. Attached latest version patch, which passed make check. > > In its current form, I'm not sure this is a good idea. Problems... >

oldhtml-stamp (was Re: [HACKERS] duplicate "median" entry in doc)

Fabien COELHO writes: > While testing with "oldhtml" I found that the "maintainer-clean" targets > in "sgml" does not clean enough: it lacks cleaning the "oldhtml-stamp". Yeah, and .gitignore fails to ignore it, too. I'm not sure if it's worth fixing ... Peter, what's the

Re: [HACKERS] Small issue in online devel documentation build

On Thu, Feb 16, 2017 at 1:05 PM, Fabien COELHO wrote: > When consulting the online "devel" documentation, for instance for > "pgbench": > > https://www.postgresql.org/docs/devel/static/pgbench.html > > Unordered lists are shown in bold, as can be seen in the -M

[HACKERS] Small issue in online devel documentation build

When consulting the online "devel" documentation, for instance for "pgbench": https://www.postgresql.org/docs/devel/static/pgbench.html Unordered lists are shown in bold, as can be seen in the -M option and in the description of random functions. This is because "ul" is in class

Re: [HACKERS] case_preservation_and_insensitivity = on

On Thu, Feb 16, 2017 at 6:53 AM, Tom Lane wrote: > Have you read any of our innumerable previous discussions about this? No, sorry, didn't see them, thanks for sharing the links. > The short answer is that nobody can see a way to modify the identifier > case-folding rules

Re: [HACKERS] duplicate "median" entry in doc

[ scratches head... ] Magic:-) While testing with "oldhtml" I found that the "maintainer-clean" targets in "sgml" does not clean enough: it lacks cleaning the "oldhtml-stamp". See attached very minor fix. -- Fabien.diff --git a/doc/src/sgml/Makefile b/doc/src/sgml/Makefile index

Re: [HACKERS] VOPS: vectorized executor for Postgres: how to speedup OLAP queries more than 10 times without changing anything in Postgres executor

On 16 February 2017 at 17:00, Konstantin Knizhnik wrote: > More progress in vectorized Postgres extension (VOPS). It is not required > any more to use some special functions in queries. > You can use vector operators in query with standard SQL and still get ten > times

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Thu, Feb 16, 2017 at 11:45 AM, Peter Geoghegan wrote: > Maybe I'm just being pedantic here, since we both actually want the > code to do the same thing. Pedantry from either of us? Nah... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Wed, Feb 15, 2017 at 6:05 PM, Thomas Munro wrote: > Here are some results with your latest patch, using the same test as > before but this time with SCALE=100 (= 100,000,000 rows). Cool. > To reduce the number of combinations I did only unique data and built >

Re: [HACKERS] VOPS: vectorized executor for Postgres: how to speedup OLAP queries more than 10 times without changing anything in Postgres executor

More progress in vectorized Postgres extension (VOPS). It is not required any more to use some special functions in queries. You can use vector operators in query with standard SQL and still get ten times improvement on some queries. VOPS extension now uses post parse analyze hook to transform

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Thu, Feb 16, 2017 at 6:28 AM, Robert Haas wrote: > On Thu, Feb 9, 2017 at 7:10 PM, Peter Geoghegan wrote: >> At the risk of stating the obvious, ISTM that the right way to do >> this, at a high level, is to err on the side of unneeded extra >> unlink()

Re: [HACKERS] duplicate "median" entry in doc

Fabien COELHO writes: > I confirm that "oldhtml" does not generate the "see also" in head, > probably because the first termindex/primary is kept and overrides the > second somehow, which is consistent with the warning. > However, after removing the duplicate, both

Re: [HACKERS] [PATCH] kNN for btree

On Thu, Feb 16, 2017 at 10:59 AM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Feb 16, 2017 at 8:05 AM, Alexander Korotkov >> wrote: >>> My idea is that we need more general redesign of specifying ordering which >>> index

Re: [HACKERS] Partitioning vs ON CONFLICT

But surely it should be possible to use DO NOTHING without inferring some particular unique index? That's possible with an approach based on inheritance. -- Peter Geoghegan (Sent from my phone)

Re: [HACKERS] duplicate "median" entry in doc

When trying to build the documentation there is a minor warning: collateindex.pl: duplicated index entry found: MEDIAN See https://www.postgresql.org/message-id/29262.1483053...@sss.pgh.pa.us I've been waiting for some clarification on that before attempting to fix this. In any case,

Re: [HACKERS] drop support for Python 2.3

Hi Peter, On Thu, 2017-02-16 at 08:21 -0500, Peter Eisentraut wrote: > > I have CentOS 5 instances running on buildfarm. I'll register them via > > buildfarm.pg.org soon. > > I will wait for that before proceeding. Sorry for the delay. Machines are ready, I think I can prepare the buildfarm

Re: [HACKERS] [PATCH] kNN for btree

Robert Haas writes: > On Thu, Feb 16, 2017 at 8:05 AM, Alexander Korotkov > wrote: >> My idea is that we need more general redesign of specifying ordering which >> index can produce. Ideally, we should replace amcanorder, amcanbackward and >>

Re: [HACKERS] Parallel Index-only scan

On Thu, Feb 16, 2017 at 3:57 PM, Rafia Sabih wrote: > > > On Thu, Feb 16, 2017 at 3:40 PM, Rafia Sabih > wrote: >> >> >> Please find the attached patch for rebased and cleaner version. >> > Please find the attached patch with a minor

Re: [HACKERS] Parallel bitmap heap scan

On Tue, Feb 14, 2017 at 10:18 PM, Robert Haas wrote: > What is the point of having a TBMSharedIterator contain a TIDBitmap > pointer? All the values in that TIDBitmap are populated from the > TBMSharedInfo, but it seems to me that the fields that are copied over >

Re: [HACKERS] duplicate "median" entry in doc

Fabien COELHO writes: > When trying to build the documentation there is a minor warning: >collateindex.pl: duplicated index entry found: MEDIAN See https://www.postgresql.org/message-id/29262.1483053...@sss.pgh.pa.us I've been waiting for some clarification on that

Re: [HACKERS] [PATCH] kNN for btree

On Thu, Feb 16, 2017 at 8:05 AM, Alexander Korotkov wrote: > My idea is that we need more general redesign of specifying ordering which > index can produce. Ideally, we should replace amcanorder, amcanbackward and > amcanorderbyop with single callback. Such callback

[HACKERS] duplicate "median" entry in doc

When trying to build the documentation there is a minor warning: collateindex.pl: duplicated index entry found: MEDIAN Indeed, the "median" index term is specified twice in "syntax.sgml". The attached patch removes the warning. -- Fabien.diff --git a/doc/src/sgml/syntax.sgml

Re: [HACKERS] UPDATE of partition key

On Thu, Feb 16, 2017 at 5:47 AM, Greg Stark wrote: > On 13 February 2017 at 12:01, Amit Khandekar wrote: >> There are a few things that can be discussed about : > > If you do a normal update the new tuple is linked to the old one using > the ctid forming a

Re: [HACKERS] UPDATE of partition key

On Thu, Feb 16, 2017 at 03:39:30PM +0530, Amit Khandekar wrote: > and then run ExecFindPartition() > again using the root. Will check. I am not sure right now how involved > that would turn out to be, but I think that logic would not change the > existing code, so in that sense

Re: [HACKERS] New CORRESPONDING clause design

Here is the implementation of the clause with the slight change, instead of doing column mapping for each side of leaf Queries in planner I make the projection nodes output to corresponding column lists only. This patch compiles and tests successfully with master branch on

Re: [HACKERS] Patch to implement pg_current_logfile() function

On Wed, Feb 15, 2017 at 4:03 PM, Alvaro Herrera wrote: > So what is going on here is that SysLogger_Start() wants to unlink the > current-logfile file if the collector is not enabled. This should > probably be split out into a separate new function, for two reasons: >

Re: [HACKERS] Parallel Append implementation

On Thu, Feb 16, 2017 at 1:34 AM, Amit Khandekar wrote: >> What I was thinking about is something like this: >> >> 1. First, take the maximum parallel_workers value from among all the >> children. >> >> 2. Second, compute log2(num_children)+1 and round up. So, for 1 >>

Re: [HACKERS] Partitioning vs ON CONFLICT

On 16 February 2017 at 14:54, Thom Brown wrote: > Hi, > > At the moment, partitioned tables have a restriction that prevents > them allowing INSERT ... ON CONFLICT ... statements: > > postgres=# INSERT INTO cities SELECT 1, 'Crawley',105000 ON CONFLICT > (city_id) DO NOTHING; >

[HACKERS] Partitioning vs ON CONFLICT

Hi, At the moment, partitioned tables have a restriction that prevents them allowing INSERT ... ON CONFLICT ... statements: postgres=# INSERT INTO cities SELECT 1, 'Crawley',105000 ON CONFLICT (city_id) DO NOTHING; ERROR: ON CONFLICT clause is not supported with partitioned tables Why do we

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Thu, Feb 16, 2017 at 7:15 AM, Robert Haas wrote: > On Mon, Feb 13, 2017 at 10:22 AM, Amit Kapila wrote: >> As discussed, attached are refactoring patches and a patch to enable >> WAL for the hash index on top of them. > > Thanks. I think that

Re: [HACKERS] Parallel Append implementation

On Wed, Feb 15, 2017 at 11:15 PM, Ashutosh Bapat wrote: > If the user is ready throw 200 workers and if the subplans can use > them to speed up the query 200 times (obviously I am exaggerating), > why not to use those? When the user set >

[HACKERS] CREATE SUBSCRIPTION uninterruptable

Hi, I've noticed that when creating a subscription, it can't be interrupted. One must wait until it times out, which takes just over 2 minutes. I'm guessing ALTER SUBSCRIPTION would have the same problem. Shouldn't we have an interrupt for this? Thom -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Partitioned tables and relfilenode

On Thu, Feb 16, 2017 at 6:32 AM, Simon Riggs wrote: > Why not vacuum all partitions? > Why not analyze all partitions? > Truncate all partitions I agree. But, we need to be careful that a database-wide VACUUM or ANALYZE doesn't hit the partitions multiple times, once for

[HACKERS] 2 doc typos

Hi, Please find attached a patch to fix 2 typos. 1) s/mypubclication/mypublication/ 2) Removed trailing comma from last column definition in example. Thanks Thom diff --git a/doc/src/sgml/ref/create_subscription.sgml b/doc/src/sgml/ref/create_subscription.sgml index 59e5ad0..250806f 100644

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Thu, Feb 9, 2017 at 7:10 PM, Peter Geoghegan wrote: > At the risk of stating the obvious, ISTM that the right way to do > this, at a high level, is to err on the side of unneeded extra > unlink() calls, not leaking files. And, to make the window for problem > ("remaining hole

Re: [HACKERS] Possible issue with expanded object infrastructure on Postgres 9.6.1

On Thu, Feb 16, 2017 at 11:45 AM, Justin Workman wrote: >> It would help to know the data types of the columns involved in this >> query; but just eyeballing it, it doesn't look like it involves any >> array operations, so it's pretty hard to believe that the expanded-object

Re: [HACKERS] CREATE TABLE with parallel workers, 10.0?

On Wed, Feb 15, 2017 at 8:13 PM, Andres Freund wrote: > I don't think general INSERTs are safe, if you consider unique indexes > and foreign keys (both setting xmax in the simple cases and multixacts > are likely to be problematic). There's no real problem with setting xmax

Re: [HACKERS] Should we cacheline align PGXACT?

On Thu, Feb 16, 2017 at 5:07 AM, Alexander Korotkov wrote: > On Wed, Feb 15, 2017 at 8:49 PM, Alvaro Herrera > wrote: >> Alexander Korotkov wrote: >> >> > Difference between master, pgxact-align-2 and pgxact-align-3 doesn't >> > exceed >> >

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

On Wed, Feb 15, 2017 at 9:36 PM, Andres Freund wrote: > 0002-hj-add-dtrace-probes-v5.patch > > Hm. I'm personally very unenthusiastic about addming more of these, and > would rather rip all of them out. I tend to believe that static > problems simply aren't a good approach

Re: [HACKERS] Possible issue with expanded object infrastructure on Postgres 9.6.1

> > It would help to know the data types of the columns involved in this > query; but just eyeballing it, it doesn't look like it involves any > array operations, so it's pretty hard to believe that the expanded-object > code could have gotten invoked intentionally. (The mere presence of > an

Re: [HACKERS] AT detach partition is broken

On Wed, Feb 15, 2017 at 7:45 PM, Amit Langote wrote: > You're right. Took this one out (except slightly tweaking the comment) in > the attached updated patch. Committed after tweaking the other comment in that function. -- Robert Haas EnterpriseDB:

Re: [HACKERS] drop support for Python 2.3

On 2/8/17 10:35, Devrim Gündüz wrote: > On Wed, 2017-02-08 at 09:16 -0500, Peter Eisentraut wrote: >> It appears that we don't have anything running 2.4. A RHEL/CentOS 5 >> system with standard components would be a good addition to the build farm. > > I have CentOS 5 instances running on

Re: [HACKERS] ICU integration

On 2/16/17 01:13, Peter Geoghegan wrote: > On Wed, Feb 15, 2017 at 9:17 PM, Peter Eisentraut > wrote: >> I have changed it to use ucol_nextSortKeyPart() when appropriate. > > I think it would be fine if the second last argument was > "sizeof(Datum)", not

Re: [HACKERS] Passing query string to workers

On Thu, Feb 16, 2017 at 5:47 PM, Rafia Sabih wrote: > Other that that I updated some comments and other cleanup things. Please > find the attached patch for the revised version. Looks good. It has passed the regression tests (with and without regress mode). Query is

Re: [HACKERS] [PATCH] kNN for btree

Hi, Nikita! I have assigned as a reviewer for this patchset. I took a fist look to these patches. At first, I'd like to notice that it's very cool that you picked up this work. I frequently hear people complains about lack of this feature. k | kNN-btree | kNN-GiST| Opt. query

Re: [HACKERS] SERIALIZABLE with parallel query

On Thu, Feb 16, 2017 at 2:58 AM, Robert Haas wrote: > On Tue, Nov 8, 2016 at 4:51 PM, Thomas Munro > wrote: >> Currently we don't generate parallel plans in SERIALIZABLE. What >> problems need to be solved to be able to do that? I'm

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

On Wed, Feb 15, 2017 at 3:33 PM, David G. Johnston wrote: > The description in the OP basically distinguishes between NORMALIZE and > ALIGN in that ALIGN, as described above, affects an INTERSECTION on the two > ranges - discarding the non-overlapping data - while

Re: [HACKERS] Passing query string to workers

On Thu, Feb 16, 2017 at 5:06 PM, Kuntal Ghosh wrote: > > >> > >> Another question is don't we need to set debug_query_string in worker? > > > > In the updated version I am setting it in ParallelQueryMain. > > > Ahh, I missed that. debug_query_string is used to show the

Re: [HACKERS] asynchronous execution

Thank you very much for testing this! At Tue, 7 Feb 2017 13:28:42 +0900, Amit Langote wrote in <9058d70b-a6b0-8b3c-091a-fe77ed0df...@lab.ntt.co.jp> > Horiguchi-san, > > On 2017/01/31 12:45, Kyotaro HORIGUCHI wrote: > > I noticed that this patch is conflicting

Re: [HACKERS] Measuring replay lag

On 14 February 2017 at 11:48, Thomas Munro wrote: > On Wed, Feb 1, 2017 at 5:21 PM, Michael Paquier > wrote: >> On Sat, Jan 21, 2017 at 10:49 AM, Thomas Munro >> wrote: >>> Ok. I see that there is a new

Re: [HACKERS] Passing query string to workers

On Sat, Feb 11, 2017 at 8:38 AM, Rafia Sabih wrote: > >> >> Another question is don't we need to set debug_query_string in worker? > > In the updated version I am setting it in ParallelQueryMain. > Ahh, I missed that. debug_query_string is used to show the log

Re: [HACKERS] Partitioned tables and relfilenode

On 10 February 2017 at 06:19, Amit Langote wrote: > the "right thing" here being that the > command's code either throws an error or warning (in some cases) if the > specified table is a partitioned table or ignores any partitioned tables > when it reads the list

Re: [HACKERS] GUC for cleanup indexes threshold.

On 15 February 2017 at 08:07, Masahiko Sawada wrote: > > It's a bug. Attached latest version patch, which passed make check. In its current form, I'm not sure this is a good idea. Problems... 1. I'm pretty sure the world doesn't need another VACUUM parameter I suggest

Re: [HACKERS] UPDATE of partition key

On 13 February 2017 at 12:01, Amit Khandekar wrote: > There are a few things that can be discussed about : If you do a normal update the new tuple is linked to the old one using the ctid forming a chain of tuple versions. This tuple movement breaks that chain. So the

Re: [HACKERS] Parallel Index-only scan

On Thu, Feb 16, 2017 at 3:40 PM, Rafia Sabih wrote: > > On Thu, Feb 16, 2017 at 1:26 PM, Rahila Syed > wrote: > >> I reviewed the patch. Overall it looks fine to me. >> >> One comment, >> >> >- if (index->amcanparallel && >> >-

Re: [HACKERS] Measuring replay lag

Hi Thomas. At 2017-02-15 00:48:41 +1300, thomas.mu...@enterprisedb.com wrote: > > Here is a new version with the buffer on the sender side as requested. This looks good. > + write_lag > + interval > + Estimated time taken for recent WAL records to be written on this > + standby

Re: [HACKERS] Parallel Index-only scan

On Thu, Feb 16, 2017 at 1:26 PM, Rahila Syed wrote: > I reviewed the patch. Overall it looks fine to me. > > One comment, > > >- if (index->amcanparallel && > >- !index_only_scan && > >+ if ((index->amcanparallel || > >+ index_only_scan)

Re: [HACKERS] UPDATE of partition key

On 16 February 2017 at 14:42, Amit Langote wrote: > On 2017/02/16 17:55, Amit Khandekar wrote: >> On 16 February 2017 at 12:57, Amit Langote wrote: >>> On 2017/02/16 15:50, Amit Khandekar wrote: On 15 February 2017 at 20:26, David Fetter

Re: [HACKERS] increasing the default WAL segment size

On Mon, Feb 6, 2017 at 11:09 PM, Beena Emerson wrote: > > Hello, > PFA the updated patches. I've started reviewing the patches. 01-add-XLogSegmentOffset-macro.patch looks clean to me. I'll post my detailed review after looking into the second patch. But, both the patches

Re: [HACKERS] LWLock optimization for multicore Power machines

Am Dienstag, den 14.02.2017, 15:53 +0300 schrieb Alexander Korotkov: > +1 > And you could try to use pg_wait_sampling > to sampling of wait > events. Okay, i'm going to try this. Currently Tomas' scripts are still running, i'll provide updates as

Re: [HACKERS] Logical replication existing data copy

398 | 25378 | r | 2017-02-16 10:04:51.945931+01 | 25398 | 25381 | r | 2017-02-16 10:04:51.945931+01 | 25398 | 25386 | r | (4 rows) -- 20170216 10:04:S -- scale 1 clients

Re: [HACKERS] UPDATE of partition key

On 2017/02/16 17:55, Amit Khandekar wrote: > On 16 February 2017 at 12:57, Amit Langote wrote: >> On 2017/02/16 15:50, Amit Khandekar wrote: >>> On 15 February 2017 at 20:26, David Fetter wrote: Does that make sense, and if so, is it super invasive to HINT that? >>> >>>

Re: [HACKERS] UPDATE of partition key

On 16 February 2017 at 12:57, Amit Langote wrote: > On 2017/02/16 15:50, Amit Khandekar wrote: >> On 15 February 2017 at 20:26, David Fetter wrote: >>> When an UPDATE can't happen, there are often ways to hint at >>> what went wrong and how to

Re: [HACKERS] GUC for cleanup indexes threshold.

On Mon, Feb 13, 2017 at 1:01 PM, Masahiko Sawada wrote: Thanks for the explanation. I've looked into the referred code. I'm still in doubt. vacuumed_pages is incremented only when there are no indexes, i.e. nindexes=0. Now, look at the following part in the patch. +

Re: [HACKERS] ICU integration

Peter Eisentraut wrote: > - Naming of collations: Are we happy with the "de%icu" naming? I might > have come up with that while reviewing the IPv6 zone index patch. ;-) > An alternative might be "de$icu" for more Oracle vibe and avoiding the > need for double quotes in some cases. (But we have

  1   2   >