Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On Mon, 16 Nov 2015 18:55:55 -0500 Robert Haas wrote: > On Mon, Nov 16, 2015 at 7:32 AM, Ildus Kurbangaliev > wrote: > > What if just create a control struct in shared memory like in other places? > > BufferDescriptors > > and BufferBlocks

Re: [HACKERS] Parallel Seq Scan

edit: maybe this is more useful? :) (gdb) bt full #0 0x00490b56 in heap_parallelscan_nextpage () No symbol table info available. #1 0x00493fdf in heap_getnext () No symbol table info available. #2 0x005c0733 in SeqNext () No symbol table info available. #3

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Tue, Nov 17, 2015 at 6:30 PM, Simon Riggs wrote: > On 17 November 2015 at 11:48, Amit Kapila wrote: > >> On Tue, Nov 17, 2015 at 5:04 PM, Simon Riggs >> wrote: >> >>> On 17 November 2015 at 11:27, Amit Kapila

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Tue, Nov 17, 2015 at 2:45 PM, Simon Riggs wrote: > On 17 November 2015 at 06:50, Amit Kapila wrote: > > >> In anycase, I went ahead and tried further reducing the CLogControlLock >> contention by grouping the transaction status updates. The

Re: [HACKERS] Parallel Seq Scan

Hi, this is the backtrace: gdb /var/lib/pgsql/9.6/data/ /var/lib/pgsql/9.6/data/core.7877 GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-64.el7 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

> 14 нояб. 2015 г., в 10:50, Amit Kapila написал(а): > > On Wed, Sep 16, 2015 at 11:22 PM, Robert Haas > wrote: > > On Wed, Sep 16, 2015 at 12:29 PM, Alexander Korotkov > >

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Tue, Nov 17, 2015 at 5:18 PM, Amit Kapila wrote: > On Tue, Nov 17, 2015 at 5:04 PM, Simon Riggs > wrote: > >> On 17 November 2015 at 11:27, Amit Kapila >> wrote: >> >> We are trying to speed up real cases, not just

Re: [HACKERS] Support for N synchronous standby servers - take 2

Oops. At Tue, 17 Nov 2015 19:40:10 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20151117.194010.17198448.horiguchi.kyot...@lab.ntt.co.jp> > Hello, > > At Tue, 17 Nov 2015 18:13:11 +0900, Masahiko Sawada > wrote in

Re: [HACKERS] Freeze avoidance of very large table.

On 17 November 2015 at 10:29, Masahiko Sawada wrote: > > > On Tue, Nov 17, 2015 at 10:45 AM, Robert Haas wrote: >> On Sun, Nov 15, 2015 at 1:47 AM, Amit Kapila >> wrote: >>> On Sat, Nov 14, 2015 at 1:19 AM, Andres Freund

Re: [HACKERS] Getting sorted data from foreign server for merge join

Thanks Robert for your comments. Please see my replies inlined. Updated patch is attached. On Fri, Nov 6, 2015 at 10:02 PM, Robert Haas wrote: > > I think this approach is generally reasonable, but I suggested parts > of it, so may be biased. I would be interested in

Re: [HACKERS] Extracting fields from 'infinity'::TIMESTAMP[TZ]

On Tue, Nov 17, 2015 at 10:57 AM, Tom Lane wrote: > Vitaly Burovoy writes: >> I suppose behavior of monotonic values (julian, century, decade, >> isoyear, millennium and year) should be the same as for epoch (which >> obviously also monotonic value).

Re: [HACKERS] Extracting fields from 'infinity'::TIMESTAMP[TZ]

Jim Nasby writes: > On 11/17/15 2:09 AM, Vitaly Burovoy wrote: >> Proposed patch has that behavior: ±infinity for epoch, julian, >> century, decade, isoyear, millennium and year; NULL for other fields. > What's the logic behind NULL here? Infinity is infinity, whether

[HACKERS] new full text search configurations

I checked new snowball site http://snowballstem.org/ and found several new stemmers appeared (as external contributions): - Irish and Czech - Object Pascal codegenerator for Snowball - Two

Re: [HACKERS] Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?

Peter Geoghegan writes: >>> Might be better to hack a special case right there (ie, embed TIDs into >>> int8s and sort the int8s) rather than try to change the type's SQL >>> declaration. > I suggested to someone else that he take a look at this as a project, > but I guess he

Re: [HACKERS] Extracting fields from 'infinity'::TIMESTAMP[TZ]

Vitaly Burovoy writes: > I suppose behavior of monotonic values (julian, century, decade, > isoyear, millennium and year) should be the same as for epoch (which > obviously also monotonic value). > Proposed patch has that behavior: +/-infinity for epoch, julian, >

Re: [HACKERS] Freeze avoidance of very large table.

On 17 November 2015 at 15:43, Jim Nasby wrote: > On 11/17/15 4:41 AM, Thom Brown wrote: >> >> Could someone post a TL;DR summary of what the current plan looks >> like? I can see there is a huge amount of discussion to trawl back >> through. I can see it's something to

Re: [HACKERS] [PATCH] better systemd integration

Peter Eisentraut writes: > I have written a couple of patches to improve the integration of the > postgres daemon with systemd. Seems like a generally reasonable thing to do. systemd is probably not going away (unfortunately IMO, but there it is). > The second patch improves

Re: [HACKERS] new full text search configurations

Hi 2015-11-17 17:28 GMT+01:00 Oleg Bartunov : > I checked new snowball site http://snowballstem.org/ and found several > new stemmers appeared (as external contributions): > > >- Irish and Czech > > Czech snowball needs recheck

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On 17 November 2015 at 11:27, Amit Kapila wrote: > Attached patch group_update_clog_v1.patch >>> implements this idea. >>> >> >> I don't think we should be doing this only for transactions that don't >> have subtransactions. >> > > The reason for not doing this

Re: [HACKERS] Extracting fields from 'infinity'::TIMESTAMP[TZ]

On 11/17/15 2:09 AM, Vitaly Burovoy wrote: I suppose behavior of monotonic values (julian, century, decade, isoyear, millennium and year) should be the same as for epoch (which obviously also monotonic value). Proposed patch has that behavior: ±infinity for epoch, julian, century, decade,

Re: [HACKERS] Question concerning XTM (eXtensible Transaction Manager API)

On Tuesday, November 17, 2015 12:43 AM, konstantin knizhnik wrote: > On Nov 16, 2015, at 11:21 PM, Kevin Grittner wrote: >> If you are saying that DTM tries to roll back a transaction after >> any participating server has entered the RecordTransactionCommit() >>

Re: [HACKERS] Freeze avoidance of very large table.

On 11/17/15 4:41 AM, Thom Brown wrote: Could someone post a TL;DR summary of what the current plan looks like? I can see there is a huge amount of discussion to trawl back through. I can see it's something to do with the visibility map. And does it avoid freezing very large tables like the

[HACKERS] [PATCH] better systemd integration

I have written a couple of patches to improve the integration of the postgres daemon with systemd. The setup that is shipped with Red Hat- and Debian-family packages at the moment is just an imitation of the old shell scripts, relying on polling by pg_ctl for readiness, with various custom pieces

Re: [HACKERS] Bug in numeric multiplication

Dean Rasheed writes: > I just noticed that div_var_fast() has almost identical code, and so > in principle it has the same vulnerability, although it obviously only > affects the transcendental functions. > I don't actually have a test case that triggers it, but it's

Re: [HACKERS] Tab completion for ALTER COLUMN SET STATISTICS

On Mon, Sep 28, 2015 at 8:48 AM, Robert Haas wrote: > On Sat, Sep 26, 2015 at 7:24 AM, Michael Paquier > wrote: >> On Sat, Sep 26, 2015 at 7:18 AM, Jeff Janes wrote: >>> If I have "alter table foo alter COLUMN bar SET

Re: [HACKERS] Support for N synchronous standby servers - take 2

Hello, At Tue, 17 Nov 2015 18:13:11 +0900, Masahiko Sawada wrote in

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Tue, Nov 17, 2015 at 5:04 PM, Simon Riggs wrote: > On 17 November 2015 at 11:27, Amit Kapila wrote: > > We are trying to speed up real cases, not just benchmarks. >>> >>> So +1 for the concept, patch is going in right direction though lets do

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On 17 November 2015 at 11:48, Amit Kapila wrote: > On Tue, Nov 17, 2015 at 5:04 PM, Simon Riggs > wrote: > >> On 17 November 2015 at 11:27, Amit Kapila >> wrote: >> >> We are trying to speed up real cases, not just

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On Thu, Nov 12, 2015 at 12:54 AM, Etsuro Fujita wrote: > Really? I think there would be not a little burden on an FDW author; when > postgres_fdw delegates to the subplan to the remote server, for example, it > would need to create a remote join query by looking at

Re: [HACKERS] Parallel Seq Scan

On Tue, Nov 17, 2015 at 6:52 AM, Bert wrote: > edit: maybe this is more useful? :) Definitely. But if you've built with --enable-debug and not stripped the resulting executable, we ought to get line numbers as well, plus the arguments to each function on the stack. That

Re: [HACKERS] Minor comment improvement to create_foreignscan_plan

On Sun, Nov 15, 2015 at 9:25 PM, Etsuro Fujita wrote: > Oops, I've found another one. I think we should update a comment in > postgresGetForeignPlan, too; add remote filtering expressions to the list of > information needed to create a ForeignScan node. Instead of

Re: [HACKERS] pageinspect patch, for showing tuple data

> >> I still have an opinion that documentation should be more verbose, than > >> your version, but I can accept your version. > > > > I am not sure that's necessary, pageinspect is for developers. > > > >> Who is going to add heap_page_item_attrs to your patch? me or you? > > > > I recall

Re: [HACKERS] eXtensible Transaction Manager API

On Fri, Nov 13, 2015 at 8:35 AM, Michael Paquier wrote: > As well as there could be FS, OS, network problems... To come back to > the point, my point is simply that I found surprising the sentence of > Konstantin upthread saying that if commit fails on some of the nodes

Re: [HACKERS] Parallel Seq Scan

On Mon, Nov 16, 2015 at 9:49 PM, Amit Kapila wrote: >> I don't understand this part. >> > > The code in question is as below: > > tqueueReceiveSlot(TupleTableSlot *slot, DestReceiver *self) > > { > .. > > if (tqueue->tupledesc != tupledesc || > > tqueue->remapinfo->natts

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On 2015-11-17 14:14:50 +0300, Ildus Kurbangaliev wrote: > 1) We can avoid constants, and use a standard steps for tranches > creation. The constants are actually a bit useful, to easily determine builtin/non-builtin stuff. > 2) We have only one global variable (BufferCtl) Don't see the

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On Sun, Nov 8, 2015 at 7:26 PM, Kouhei Kaigai wrote: > The attached patch is an adjusted version of the previous one. > Even though it co-exists a new callback and fdw_recheck_quals, > the callback is kicked first as follows. This seems excessive to me: why would we need an

Re: [HACKERS] Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?

On Tue, Nov 17, 2015 at 7:54 AM, Tom Lane wrote: > I think this might do the wrong thing with block numbers above 0x8000 > and/or offset numbers above 0x8000. I'd be more comfortable about it if > + encoded = ((int64) block << 16) | offset; > were > + encoded

Re: [HACKERS] [PATCH] Skip ALTER x SET SCHEMA if the schema didn't change

On Mon, Nov 16, 2015 at 4:27 AM, Marti Raudsepp wrote: > Thank you so much for the review and patch update. I should have done that > myself, but I've been really busy for the last few weeks. :( Maybe I'm having an attack of the stupids today, but it looks to me like the changes

Re: [HACKERS] [COMMITTERS] pgsql: Cause TestLib.pm to define $windows_os in all branches.

On 11/17/2015 02:15 PM, Tom Lane wrote: Michael Paquier writes: On Tue, Oct 13, 2015 at 10:17 PM, Andrew Dunstan wrote: In general I think we can be a good deal more liberal about backpatching the testing regime than we are with production code, where we are

Re: [HACKERS] Bug in numeric multiplication

I wrote: > I pushed this, but while looking at it, my attention was drawn to this > bit down near the end of the loop: > /* > * The dividend digit we are about to replace might still be nonzero. > * Fold it into the next digit position. We don't need to worry about >

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

> On Sun, Nov 8, 2015 at 7:26 PM, Kouhei Kaigai wrote: > > The attached patch is an adjusted version of the previous one. > > Even though it co-exists a new callback and fdw_recheck_quals, > > the callback is kicked first as follows. > > This seems excessive to me: why

Re: [HACKERS] [COMMITTERS] pgsql: Cause TestLib.pm to define $windows_os in all branches.

On Wed, Nov 18, 2015 at 4:15 AM, Tom Lane wrote: > I'm not in a position to double-check that these patches work on Windows, > but I reviewed them through the expedient of diff'ing the patched files > against HEAD. I'll double-check things a bit and post replies on this thread should I detect a

Re: [HACKERS] proposal: multiple psql option -c

On 11/17/2015 04:13 PM, Tom Lane wrote: Robert Haas writes: A few years ago there was a proposal to not only allow multiple -c options, but to allow -c and -f to be intermingled. This seems really rather useful; I'd like to be able to type psql -c do_this_first -f

Re: [HACKERS] Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?

On Tue, Nov 17, 2015 at 12:53 AM, Simon Riggs wrote: > Short and sweet! Looks good. Thanks. > I would be inclined to add more comments to explain it, these things have a > habit of being forgotten. I'm not sure what additional detail I can add. I seem to be able to

Re: [HACKERS] Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?

On Wed, Nov 18, 2015 at 8:50 AM, Peter Geoghegan wrote: > I seem to be able to produce these sorting patches at a much greater > rate than they can be committed, in part because Robert is the only > one that ever reviews them, and he is only one person. Since you think > the patch is good work,

Re: [HACKERS] proposal: multiple psql option -c

Robert Haas writes: > On Mon, Nov 16, 2015 at 6:05 PM, Andrew Dunstan wrote: >> I honestly don't see what's so confusing about it, and if there is any >> confusion then surely we could make sure what's happening is well >> documented. > +1. I'm

Re: [HACKERS] Parallel Seq Scan

On Thu, Nov 12, 2015 at 10:23 AM, Amit Kapila wrote: > Thanks for the report. The reason for this problem is that instrumentation > information from workers is getting aggregated multiple times. In > ExecShutdownGatherWorkers(), we call ExecParallelFinish where it >

Re: [HACKERS] proposal: multiple psql option -c

> Well, it's not *entirely* true that it has only backwards compatibility > to recommend it: without -c in its current form, there would be no way > to test multiple-commands-in-one-PQexec cases without hacking up some > custom test infrastructure. That's not a very strong reason maybe, but >

Re: [HACKERS] Bug in numeric multiplication

Dean Rasheed writes: > On 17 November 2015 at 14:43, Tom Lane wrote: >> Hm, good point. I don't feel a compulsion to have a test case that >> proves it's broken before we fix it. Do you want to send a patch? > OK, here it is. It's slightly

Re: [HACKERS] proposal: multiple psql option -c

On Mon, Nov 16, 2015 at 6:05 PM, Andrew Dunstan wrote: > I honestly don't see what's so confusing about it, and if there is any > confusion then surely we could make sure what's happening is well > documented. +1. I'm actually kind of wondering if we should just back up and

Re: [HACKERS] proposal: multiple psql option -c

2015-11-17 21:00 GMT+01:00 Robert Haas : > On Tue, Nov 17, 2015 at 2:25 PM, Tom Lane wrote: > > Robert Haas writes: > >> On Mon, Nov 16, 2015 at 6:05 PM, Andrew Dunstan > wrote: > >>> I honestly don't see

Re: [HACKERS] [DESIGN] ParallelAppend

On Tue, Nov 17, 2015 at 4:26 AM, Thom Brown wrote: > Okay, I've tried this patch. Thanks! > Yes, it's working! Woohoo. > However, the first parallel seq scan shows it getting 170314 rows. > Another run shows it getting 194165 rows. The final result is > correct, but as you

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

On 11/6/15 3:59 PM, Robert Haas wrote: > So, I really wonder why we're not happy with the ability to substitute > out just the host and IP. One of my concerns is that the proposed URLs are not valid URLs anymore that can be parsed or composed with a URL library, which would be sad. The other

Re: [HACKERS] Question concerning XTM (eXtensible Transaction Manager API)

konstantin knizhnik wrote: > The transaction is normally committed in xlog, so that it can always be > recovered in case of node fault. > But before setting correspondent bit(s) in CLOG and releasing locks we first > contact arbiter to get global status of transaction. > If it is successfully

Re: [HACKERS] pg_receivexlog: spurious error message connecting to 9.3

On Tue, Nov 10, 2015 at 1:35 AM, Craig Ringer wrote: > On 10 November 2015 at 01:47, Marco Nenciarini > wrote: > >> I've attached a little patch that removes the errors when connected to 9.3. > > Looks good to me. No point confusing users.

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

On 26 October 2015 at 07:58, Victor Wagner wrote: > On 2015.10.14 at 13:41:51 +0300, Victor Wagner wrote: > >> Attached patch which implements client library failover and >> loadbalancing as was described in the proposal >> <20150818041850.ga5...@wagner.pp.ru>. > > New version

Re: [HACKERS] Bug in numeric multiplication

On 17 November 2015 at 14:43, Tom Lane wrote: > Dean Rasheed writes: >> I just noticed that div_var_fast() has almost identical code, and so >> in principle it has the same vulnerability, although it obviously only >> affects the transcendental

Re: [HACKERS] proposal: multiple psql option -c

On Tue, Nov 17, 2015 at 2:25 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Nov 16, 2015 at 6:05 PM, Andrew Dunstan wrote: >>> I honestly don't see what's so confusing about it, and if there is any >>> confusion then surely

Re: [HACKERS] [PATCH] SQL function to report log message

On 11/17/15 2:16 AM, Jim Nasby wrote: > On 11/15/15 10:56 PM, dinesh kumar wrote: >> So, shall we make this pg_report_log TO pg_write_log OR pg_ereport OR >> from you. > > Why not pg_raise to mirror plpgsql? (The function does have the same > semantics, right? It's not doing something like only

Re: [HACKERS] Freeze avoidance of very large table.

On Wed, Nov 18, 2015 at 12:56 AM, Thom Brown wrote: > On 17 November 2015 at 15:43, Jim Nasby wrote: >> On 11/17/15 4:41 AM, Thom Brown wrote: >>> >>> Could someone post a TL;DR summary of what the current plan looks >>> like? I can see there is a huge

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

> > On Sun, Nov 8, 2015 at 7:26 PM, Kouhei Kaigai wrote: > > > The attached patch is an adjusted version of the previous one. > > > Even though it co-exists a new callback and fdw_recheck_quals, > > > the callback is kicked first as follows. > > > > This seems excessive to

Re: [HACKERS] Minor comment improvement to create_foreignscan_plan

On 2015/11/18 2:57, Robert Haas wrote: On Sun, Nov 15, 2015 at 9:25 PM, Etsuro Fujita wrote: Oops, I've found another one. I think we should update a comment in postgresGetForeignPlan, too; add remote filtering expressions to the list of information needed to

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/11/18 3:19, Robert Haas wrote: On Thu, Nov 12, 2015 at 12:54 AM, Etsuro Fujita wrote: Really? I think there would be not a little burden on an FDW author; when postgres_fdw delegates to the subplan to the remote server, for example, it would need to create

Re: [HACKERS] [PATCH] Skip ALTER x SET SCHEMA if the schema didn't change

On Wed, Nov 18, 2015 at 6:02 AM, Robert Haas wrote: > On Mon, Nov 16, 2015 at 4:27 AM, Marti Raudsepp wrote: >> Thank you so much for the review and patch update. I should have done that >> myself, but I've been really busy for the last few weeks. :( > >

Re: [HACKERS] Parallel Seq Scan

On Wed, Nov 18, 2015 at 12:59 AM, Robert Haas wrote: > > On Thu, Nov 12, 2015 at 10:23 AM, Amit Kapila wrote: > > Thanks for the report. The reason for this problem is that instrumentation > > information from workers is getting aggregated

Re: [HACKERS] Parallel Seq Scan

On Tue, Nov 17, 2015 at 4:51 PM, Bert wrote: > Hey Robert, > > Thank you for the help. As you might (not) know, I'm quite new to the > community, but I'm learning. with the help from people like you. > anyhow, find attached a third attempt to a valid backtrace file. > > This

Re: [HACKERS] Parallel Seq Scan

On Tue, Nov 17, 2015 at 11:22 PM, Robert Haas wrote: > > On Mon, Nov 16, 2015 at 9:49 PM, Amit Kapila wrote: > >> I don't understand this part. > >> > > > > Here the above check always passes as tqueue->tupledesc is not > > set due to which it

Re: [HACKERS] Conversion error of floating point numbers in pl/pgsql

On Tue, Nov 17, 2015 at 9:00 PM, Robert Haas wrote: > On Mon, Nov 16, 2015 at 9:49 AM, Tom Lane wrote: >> Kyotaro HORIGUCHI writes: >>> Hello. I found that 9.5 has an undocumented difference from 9.4 >>> in type cast in

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On Tue, Nov 17, 2015 at 6:51 PM, Kouhei Kaigai wrote: > It just intends to keep code symmetry with custom-scan case, so not > a significant reason. > And, I expected ForeignScan will also need multiple sub-plans soon > to support more intelligent push-down like: >

Re: [HACKERS] Conversion error of floating point numbers in pl/pgsql

On Mon, Nov 16, 2015 at 9:49 AM, Tom Lane wrote: > Kyotaro HORIGUCHI writes: >> Hello. I found that 9.5 has an undocumented difference from 9.4 >> in type cast in pl/pgsql and I think it might better be mentioned >> as a change of behavior in

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

> On Tue, Nov 17, 2015 at 6:51 PM, Kouhei Kaigai wrote: > > It just intends to keep code symmetry with custom-scan case, so not > > a significant reason. > > And, I expected ForeignScan will also need multiple sub-plans soon > > to support more intelligent push-down like: >

Re: [HACKERS] Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?

On Tue, Nov 17, 2015 at 7:28 PM, Michael Paquier wrote: > On Wed, Nov 18, 2015 at 8:50 AM, Peter Geoghegan wrote: > > I seem to be able to produce these sorting patches at a much greater > > rate than they can be committed, in part because Robert is the only > > one

Re: [HACKERS] Extracting fields from 'infinity'::TIMESTAMP[TZ]

On 11/9/15, Robert Haas wrote: > On Sat, Nov 7, 2015 at 9:47 AM, Vitaly Burovoy > wrote: >> I'd like to raise a topic about extracting fields from infinite >> timestamps, so much more that it is mentioned in the TODO list: >> "Determine how to

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Tue, Nov 17, 2015 at 1:32 PM, Amit Kapila wrote: > > On Mon, Sep 21, 2015 at 6:34 AM, Peter Geoghegan wrote: > > > > On Mon, Aug 31, 2015 at 9:49 PM, Amit Kapila wrote: > > > Increasing CLOG buffers to 64 helps in reducing

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Mon, Sep 21, 2015 at 6:34 AM, Peter Geoghegan wrote: > > On Mon, Aug 31, 2015 at 9:49 PM, Amit Kapila wrote: > > Increasing CLOG buffers to 64 helps in reducing the contention due to second > > reason. Experiments revealed that increasing CLOG

Re: [HACKERS] Freeze avoidance of very large table.

On Tue, Nov 17, 2015 at 10:45 AM, Robert Haas > wrote: > On Sun, Nov 15, 2015 at 1:47 AM, Amit Kapila > wrote: >> On Sat, Nov 14, 2015 at 1:19 AM, Andres Freund > wrote: >>> On 2015-10-31

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Tue, Nov 17, 2015 at 9:57 AM, Kyotaro HORIGUCHI wrote: > Hello, > > At Tue, 17 Nov 2015 01:09:57 +0900, Masahiko Sawada > wrote in

Re: [HACKERS] [DESIGN] ParallelAppend

On 13 November 2015 at 22:09, Robert Haas wrote: > On Thu, Nov 12, 2015 at 12:09 AM, Kouhei Kaigai wrote: >> I'm now designing the parallel feature of Append... >> >> Here is one challenge. How do we determine whether each sub-plan >> allows execution

Re: [HACKERS] Making tab-complete.c easier to maintain

Hello, I tried to implement the mini-language, which is a simplified reglar expression for this specific use. As a ultra-POC, the attached patch has very ad-hoc preprocess function and does on-the-fly preprocessing, compilation then execution of regular expression. And it is applied to only the

Re: [HACKERS] Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?

On 17 November 2015 at 00:52, Peter Geoghegan wrote: > This patch does seem like a slam dunk, even if I do say so myself Short and sweet! Looks good. I would be inclined to add more comments to explain it, these things have a habit of being forgotten. -- Simon Riggs

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On 17 November 2015 at 06:50, Amit Kapila wrote: > In anycase, I went ahead and tried further reducing the CLogControlLock > contention by grouping the transaction status updates. The basic idea > is same as is used to reduce the ProcArrayLock contention [1] which is

Re: [HACKERS] Question concerning XTM (eXtensible Transaction Manager API)

On Nov 17, 2015, at 10:44 AM, Amit Kapila wrote: > > I think the general idea is that if Commit is WAL logged, then the > operation is considered to committed on local node and commit should > happen on any node, only once prepare from all nodes is successful. > And after that transaction is

Re: [HACKERS] Bug in numeric multiplication

On 21 September 2015 at 17:14, Tom Lane wrote: > Dean Rasheed writes: >> On 21 September 2015 at 16:09, Tom Lane wrote: >>> After trying to rework the comment to explain what maxdig really meant >>> after your changes, I came to

Re: [HACKERS] pageinspect patch, for showing tuple data

Hi, Le 12 nov. 2015 1:05 AM, "Michael Paquier" a écrit : > > On Thu, Nov 12, 2015 at 12:41 AM, Nikolay Shaplov > wrote: > > В письме от 28 октября 2015 16:57:36 пользователь Michael Paquier написал: > >> On Sat, Oct 17, 2015 at 1:48 AM,

Re: [HACKERS] Erroneous cost estimation for nested loop join

On Mon, Nov 16, 2015 at 6:50 PM, Jeff Janes wrote: > On Mon, Nov 9, 2015 at 6:37 AM, Tom Lane wrote: >> kawami...@tkl.iis.u-tokyo.ac.jp writes: >>> - cost parameter calibration: random_page_cost = 92.89 >> >> TBH, you lost me there already. I know

Re: [HACKERS] [COMMITTERS] pgsql: Cause TestLib.pm to define $windows_os in all branches.

Michael Paquier writes: > On Tue, Oct 13, 2015 at 10:17 PM, Andrew Dunstan wrote: >> In general I think we can be a good deal more liberal about backpatching the >> testing regime than we are with production code, where we are always >> cautious, and the caution has

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

On 11/5/15 10:12 AM, Victor Wagner wrote: > 2. You are suggesting that it should be possible to specify all options > separately for each of the fallback hosts. I'm not necessarily suggesting that. I think it could very well be conn="postgresql://foo postgresql://bar order=random" -- Sent

Re: [HACKERS] Default Roles (was: Additional role attributes)

Michael, * Michael Paquier (michael.paqu...@gmail.com) wrote: > Will there be any work on this patch for this commit fest or not? This > is being carried around for a couple of months now with not much > progress. This thread is idle for 4 months now. This thread and the other one kind of

Re: [HACKERS] Parallel Seq Scan

Hey Robert, Thank you for the help. As you might (not) know, I'm quite new to the community, but I'm learning. with the help from people like you. anyhow, find attached a third attempt to a valid backtrace file. This run is compiled from commit 5f10b7a604c87fc61a2c20a56552301f74c9bd5f and your

Re: [HACKERS] proposal: multiple psql option -c

Robert Haas writes: > A few years ago there was a proposal to not only allow multiple -c > options, but to allow -c and -f to be intermingled. This seems really > rather useful; I'd like to be able to type psql -c do_this_first -f > script.sql and have that work. But of

Re: [HACKERS] [DESIGN] ParallelAppend

On 17 November 2015 at 20:08, Robert Haas wrote: > On Tue, Nov 17, 2015 at 4:26 AM, Thom Brown wrote: > >> However, the first parallel seq scan shows it getting 170314 rows. >> Another run shows it getting 194165 rows. The final result is >> correct, but

Re: [HACKERS] Freeze avoidance of very large table.

On Tue, Nov 17, 2015 at 7:29 PM, Masahiko Sawada wrote: > > > On Tue, Nov 17, 2015 at 10:45 AM, Robert Haas wrote: >> On Sun, Nov 15, 2015 at 1:47 AM, Amit Kapila >> wrote: >>> On Sat, Nov 14, 2015 at 1:19 AM, Andres Freund

Re: [HACKERS] pageinspect patch, for showing tuple data

On Wed, Nov 18, 2015 at 3:10 AM, Nikolay Shaplov wrote: > Everything seems to be ok. I've changed only one thing in your version > of the patch. I've renamed split_tuple_data to > tuple_data_split_internal, because when there are split_tuple_data and > tuple_data_split in the same file, nobody

Re: [HACKERS] Default Roles (was: Additional role attributes)

On Wed, Nov 18, 2015 at 5:36 AM, Stephen Frost wrote: > Michael, > > * Michael Paquier (michael.paqu...@gmail.com) wrote: >> Will there be any work on this patch for this commit fest or not? This >> is being carried around for a couple of months now with not much >> progress.

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

On Tue, 17 Nov 2015 19:42:42 + Thom Brown wrote: > > This patch doesn't apply. On line 636, this appears: It doesn't apply to current state of the master branch due to changes in fe-connect.c made by Tom Lane in the commit c40591885. Unfortunately these changes appears in