[HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Fri, Sep 25, 2015 at 3:11 PM, Amir Rohan wrote: > On 08/14/2015 06:32 AM, Michael Paquier wrote: > > On Fri, Aug 14, 2015 at 12:54 AM, Michael Paquier > > wrote: > >> On Mon, Jun 29, 2015 at 10:11 PM, Michael Paquier > >> wrote: > >>> On Wed, Mar 18, 2015 at 1:59 PM, Michael Paquier > >>> w

[HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On 08/14/2015 06:32 AM, Michael Paquier wrote: > On Fri, Aug 14, 2015 at 12:54 AM, Michael Paquier > wrote: >> On Mon, Jun 29, 2015 at 10:11 PM, Michael Paquier >> wrote: >>> On Wed, Mar 18, 2015 at 1:59 PM, Michael Paquier >>> wrote: Feedback is of course welcome, but note that I am not se

Re: [HACKERS] Doubt in pgbench TPS number

Hello Tatsuo-san, $ pgbench -C -n -p 11002 -c 10 -T 30 -f test.sql test tps = 95.799114 (including connections establishing) tps = 124.487149 (excluding connections establishing) Interesting thing is, the number from "excluding connections establishing". 124.487149 tps means 0.008032 seconds

Re: [HACKERS] TEXT vs VARCHAR join qual push down diffrence, bug or expected?

On Thu, Sep 24, 2015 at 10:22 PM, Tom Lane wrote: > Jeevan Chalke writes: > > On Wed, Sep 23, 2015 at 10:15 PM, Tom Lane wrote: > >> After a bit more thinking and experimentation, I propose the attached > >> patch. > > > I had a look over the patch and reviewed it. It is in excellent state to >

Re: [HACKERS] Decimal64 and Decimal128

2015-09-25 0:25 GMT+02:00 Jim Nasby : > On 9/24/15 3:35 PM, Peter Geoghegan wrote: > >> I would worry about the implicit casts you've added. They might cause >> problems. >> > > Given the cycle created between numeric->decimal and decimal->numeric, I > can pretty much guarantee they will. In any c

Re: [HACKERS] Parallel Seq Scan

On Fri, Sep 25, 2015 at 8:50 AM, Robert Haas wrote: > > On Thu, Sep 24, 2015 at 2:31 PM, Amit Kapila wrote: > > I have fixed most of the review comments raised in this mail > > as well as other e-mails and rebased the patch on commit- > > 020235a5. Even though I have fixed many of the things, bu

[HACKERS] Doubt in pgbench TPS number

Today I got an interesting output from pgbench. The scenario is executing SELECT pg_sleep(0.1). $ cat test.sql select pg_sleep(0.1); $ pgbench -C -n -p 11002 -c 10 -T 30 -f test.sql test transaction type: Custom query scaling factor: 1 query mode: simple number of clients: 10 number of threads:

Re: [HACKERS] Parallel Seq Scan

On Thu, Sep 24, 2015 at 12:00 AM, Robert Haas wrote: > > On Thu, Sep 3, 2015 at 6:21 AM, Amit Kapila wrote: > > [ new patches ] > > > It looks to me like there would be trouble if an initPlan or subPlan > were kept below a Funnel, or as I guess we're going to call it, a > Gather node. That's bec

Re: [HACKERS] Parallel Seq Scan

On Thu, Sep 24, 2015 at 2:31 PM, Amit Kapila wrote: > I have fixed most of the review comments raised in this mail > as well as other e-mails and rebased the patch on commit- > 020235a5. Even though I have fixed many of the things, but > still quite a few comments are yet to be handled. This pat

[HACKERS] Manual bitswizzling -> LOCKBIT_ON

Hi While studying lmgr code, I noticed that there are a couple of places that use 1 << x to convert a LOCKMODE to a LOCKMASK instead of the macro that is used elsewhere. Should that be changed for consistency, as in the attached? -- Thomas Munro http://www.enterprisedb.com use-lockbit-on-macr

Re: [HACKERS] PATCH: use foreign keys to improve join estimates v1

On 24 September 2015 at 23:57, Tomas Vondra wrote: > > 2) find_best_match_foreign_key > -- > > I think the comment before the function needs rephrasing (seems a bit > broken to me). I do like the approach in general, although it changes the > semantics a bit. The origi

[HACKERS] CustomScan support on readfuncs.c

Hi, I tried to define two additional callbacks to support CustomScan on readfuncs.c. First of all, we need to pay attention how to treat output of TextOutCustomScan when additional text output is generated. Only custom-scan provider knows what shall be displayed, so all we can do is invoke a new

Re: [HACKERS] DBT-3 with SF=20 got failed

On Thu, Sep 24, 2015 at 1:58 PM, Tomas Vondra wrote: > Meh, you're right - I got the math wrong. It's 1.3% in both cases. > > However the question still stands - why should we handle the over-estimate > in one case and not the other? We're wasting the same fraction of memory in > both cases. Well

Re: [HACKERS] Decimal64 and Decimal128

On Fri, Sep 25, 2015 at 10:25 AM, Jim Nasby wrote: > On 9/24/15 3:35 PM, Peter Geoghegan wrote: >> >> I would worry about the implicit casts you've added. They might cause >> problems. > > > Given the cycle created between numeric->decimal and decimal->numeric, I can > pretty much guarantee they w

Re: [HACKERS] Rename withCheckOptions to insertedCheckClauses

On 24 September 2015 at 21:25, Tom Lane wrote: > I wrote: >> - List *ri_WithCheckOptions; >> - List *ri_WithCheckOptionExprs; >> + List *ri_InsertedCheckClauses; >> + List *ri_InsertedCheckClauseExprs; > >> The distinction between a "clause" and an "expr" is

Re: [HACKERS] Decimal64 and Decimal128

On 09/24/2015 02:23 PM, Feng Tian wrote: > If there is enough interest, would be great for it to go into the > official contrib dir. > Thanks, > > > Second thought, the extension depends on decNumber, which is either GPL, > or ICU license. Maybe this is trouble. > Yes. Please ju

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

Josh Berkus writes: > On 09/24/2015 12:55 PM, Tom Lane wrote: >> I agree with the idea that we don't yet want to give the impression that >> this is the official bug tracker. However, "beta-bugs" could give the >> impression that it was specifically for bugs about 9.5beta, without >> dispelling t

Re: [HACKERS] Bad row estimation with indexed func returning bool

I wrote: >> The implication of doing it like this would be that the default estimate >> in the absence of any matching stats would be 0.5 (since eqsel defaults >> to 1/ndistinct, and get_variable_numdistinct will report 2.0 for any >> boolean-type expression it has no stats for). That's not a huge

Re: [HACKERS] 9.3.9 and pg_multixact corruption

Jim Nasby wrote: > On 9/20/15 9:23 AM, Christoph Berg wrote: > >a short update here: the customer updated the compiler to a newer > >version, is now compiling using -O2 instead of -O3, and the code > >generated now looks sane, so this turned out to be a compiler issue. > >(Though it's unclear if th

Re: [HACKERS] 9.3.9 and pg_multixact corruption

On 9/20/15 9:23 AM, Christoph Berg wrote: a short update here: the customer updated the compiler to a newer version, is now compiling using -O2 instead of -O3, and the code generated now looks sane, so this turned out to be a compiler issue. (Though it's unclear if the upgrade fixed it, or the di

Re: [HACKERS] Decimal64 and Decimal128

On 9/24/15 3:35 PM, Peter Geoghegan wrote: I would worry about the implicit casts you've added. They might cause problems. Given the cycle created between numeric->decimal and decimal->numeric, I can pretty much guarantee they will. In any case, I don't think implicit casting from numeric->de

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On 9/24/15 7:37 AM, Masahiko Sawada wrote: * The progress of VACUUM FULL seems wrong. When I run VACUUM FULL for a table, I got following progress. It never occurred to me that this patch was attempting to measure the progress of a CLUSTER (aka VACUUM FULL). I'm not sure that's such a great i

Re: [HACKERS] Decimal64 and Decimal128

On Fri, Sep 25, 2015 at 9:23 AM, Feng Tian wrote: > > > On Thu, Sep 24, 2015 at 2:17 PM, Feng Tian wrote: >> >> >> >> On Thu, Sep 24, 2015 at 1:55 PM, Peter Geoghegan wrote: >>> >>> On Thu, Sep 24, 2015 at 1:53 PM, Tom Lane wrote: >>> > Please include the actual patch as an attachment. We do n

Re: [HACKERS] Decimal64 and Decimal128

On 25 September 2015 at 08:29, Feng Tian wrote: > Compared to numeric type, decimal64 arithmetics is about 2x faster, > decimal128 is about 1.5x faster. However, the cast between decimal and > float4/8 is implemented rather naively and slow. As always, it depends on > workload, decimal may tak

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/24/2015 12:55 PM, Tom Lane wrote: > Stephen Frost writes: >> Are there any objections to pginfra standing up bugs.postgresql.org with >> debbugs? Obviously, it'd be more-or-less beta as we play with it, and >> we could set it up as beta-bugs.p.o, if there's concern about that. > > I agree

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/24/2015 07:03 PM, Josh Berkus wrote: > On 09/23/2015 10:25 PM, Thomas Munro wrote: >> On Thu, Sep 24, 2015 at 1:31 PM, Joe Conway wrote: >>> On 09/23/2015 05:21 PM, Thomas Munro wrote: Do you think it would make any sense to consider evolving what we have already? At the moment, w

Re: [HACKERS] Decimal64 and Decimal128

On Thu, Sep 24, 2015 at 2:17 PM, Feng Tian wrote: > > > On Thu, Sep 24, 2015 at 1:55 PM, Peter Geoghegan wrote: > >> On Thu, Sep 24, 2015 at 1:53 PM, Tom Lane wrote: >> > Please include the actual patch as an attachment. We do not consider >> mere >> > URLs to be acceptable patch submission fo

Re: [HACKERS] Decimal64 and Decimal128

On Thu, Sep 24, 2015 at 1:55 PM, Peter Geoghegan wrote: > On Thu, Sep 24, 2015 at 1:53 PM, Tom Lane wrote: > > Please include the actual patch as an attachment. We do not consider > mere > > URLs to be acceptable patch submission format, because that provides no > > permanent record in our arch

Re: [HACKERS] Decimal64 and Decimal128

On Thu, Sep 24, 2015 at 1:53 PM, Tom Lane wrote: > Please include the actual patch as an attachment. We do not consider mere > URLs to be acceptable patch submission format, because that provides no > permanent record in our archives of what was submitted. I was under the impression that this wa

Re: [HACKERS] Decimal64 and Decimal128

Feng Tian writes: > Ah, link. > https://github.com/vitesse-ftian/pgdecimal Please include the actual patch as an attachment. We do not consider mere URLs to be acceptable patch submission format, because that provides no permanent record in our archives of what was submitted.

Re: [HACKERS] Decimal64 and Decimal128

On Thu, Sep 24, 2015 at 1:29 PM, Feng Tian wrote: > Here is an extension for 64 and 128 bit decimal types using IEEE decimal > floating point. The original idea/implementation is from > http://pgxn.org/dist/pgdecimal/1.0.0/ Interesting. A default B-Tree operator class for the decimal types would

Re: [HACKERS] Decimal64 and Decimal128

On Thu, Sep 24, 2015 at 1:29 PM, Feng Tian wrote: > Hi, > > Here is an extension for 64 and 128 bit decimal types using IEEE decimal > floating point. The original idea/implementation is from > http://pgxn.org/dist/pgdecimal/1.0.0/ Original thread for dicussion is > at > > > http://www.postgre

[HACKERS] Decimal64 and Decimal128

Hi, Here is an extension for 64 and 128 bit decimal types using IEEE decimal floating point. The original idea/implementation is from http://pgxn.org/dist/pgdecimal/1.0.0/ Original thread for dicussion is at http://www.postgresql.org/message-id/CAFj8pRApakE6s-H2yJcXD=ubpukwa6i7rx4vuvtb4puhga5.

Re: [HACKERS] Rename withCheckOptions to insertedCheckClauses

I wrote: > - List *ri_WithCheckOptions; > - List *ri_WithCheckOptionExprs; > + List *ri_InsertedCheckClauses; > + List *ri_InsertedCheckClauseExprs; > The distinction between a "clause" and an "expr" is not very obvious, > and certainly most other places in

Re: [HACKERS] PGXS "check" target forcing an install ?

On Fri, Jun 26, 2015 at 09:09:15AM -0400, Robert Haas wrote: > On Tue, Jun 23, 2015 at 1:31 AM, Michael Paquier > wrote: > >> I tracked the dangerous -rf to come from Makefile.global and it's empty > >> string being due to abs_top_builddir not being define in my own Makefile. > >> But beside that

Re: [HACKERS] Rename withCheckOptions to insertedCheckClauses

Stephen Frost writes: > Alright, attached is an attempt at doing these renames. I went a bit > farther since it seemed to make sense to me (at least at the time, I'm > wondering a bit about it now), so, please provide any thoughts or > feedback you have regarding these changes. > Further, rename

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > Are there any objections to pginfra standing up bugs.postgresql.org with > > debbugs? Obviously, it'd be more-or-less beta as we play with it, and > > we could set it up as beta-bugs.p.o, if there's concern about that. > > I agre

Re: [HACKERS] row_security GUC, BYPASSRLS

On Tue, Sep 22, 2015 at 10:38:53AM -0400, Stephen Frost wrote: > * Noah Misch (n...@leadboat.com) wrote: > > On Mon, Sep 21, 2015 at 09:30:15AM -0400, Stephen Frost wrote: > > > One item which wasn't discussed, that I recall, is just how it will work > > > without SECURITY_ROW_LEVEL_DISABLED, or so

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

Stephen Frost writes: > Are there any objections to pginfra standing up bugs.postgresql.org with > debbugs? Obviously, it'd be more-or-less beta as we play with it, and > we could set it up as beta-bugs.p.o, if there's concern about that. I agree with the idea that we don't yet want to give the

[HACKERS] Rename withCheckOptions to insertedCheckClauses

All, and this totally should have gone to -hackers instead, sorry about that. Please ignore the one to -committers, if possible. Tom, all, * Tom Lane (t...@sss.pgh.pa.us) wrote: > My vote would be to rename and reposition the field in HEAD and 9.5 > and accept the corresponding initdb. We alrea

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

All, * Stephen Frost (sfr...@snowman.net) wrote: > Not saying it's perfect, of course, but it's probably the best option > for minimizing impact on our existing process. I discussed the current state of debbugs with Don Armstrong (one of the main individuals behind it) and his opinion is that deb

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On Thu, Sep 24, 2015 at 12:10:07PM -0600, Ryan Pedela wrote: > Kam Lasater wrote: > > I'd suggest: Github Issues, Pivotal Tracker or Redmine (probably in > > that order). There are tens to hundreds of other great ones out there, > > I'm sure one of them would also work. > > Why not just use Github

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On Thu, Sep 24, 2015 at 6:16 PM, Tom Lane wrote: > Yeah; "let's write our own bug tracker" is a good way to make sure nothing > comes of this. On the other hand, "let's get all the Postgres hackers to > change their habits" is an equally good way to make sure nothing comes of > this. I think th

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

Kam Lasater wrote: > I'd suggest: Github Issues, Pivotal Tracker or Redmine (probably in > that order). There are tens to hundreds of other great ones out there, > I'm sure one of them would also work. Why not just use Github issues? 1. You can set it up to send emails to the list when an issue i

Re: [HACKERS] clearing opfuncid vs. parallel query

Robert Haas writes: > On Thu, Sep 24, 2015 at 12:35 PM, Tom Lane wrote: >> For the record: that's true for the patch you just committed. But once >> I remove the hopefully-now-dead planner support for recomputing opfuncid, >> it would get a lot more painful to reverse the decision. > True. I t

Re: [HACKERS] DBT-3 with SF=20 got failed

On 09/24/2015 07:42 PM, Robert Haas wrote: On Thu, Sep 24, 2015 at 12:40 PM, Tomas Vondra wrote: There are two machines - one with 32GB of RAM and work_mem=2GB, the other one with 256GB of RAM and work_mem=16GB. The machines are hosting about the same data, just scaled accordingly (~8x more d

Re: [HACKERS] clearing opfuncid vs. parallel query

On Thu, Sep 24, 2015 at 12:35 PM, Tom Lane wrote: > Robert Haas writes: >> Also, it's not like this change couldn't be UN-done at a future point. >> I mean, Tom didn't like the flag I added aesthetically, but if we >> needed it, we could have it. Or we could engineer something else. > > For the

Re: [HACKERS] DBT-3 with SF=20 got failed

On Thu, Sep 24, 2015 at 12:40 PM, Tomas Vondra wrote: > There are two machines - one with 32GB of RAM and work_mem=2GB, the other > one with 256GB of RAM and work_mem=16GB. The machines are hosting about the > same data, just scaled accordingly (~8x more data on the large machine). > > Let's assum

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/24/2015 10:24 AM, Stephen Frost wrote: > * Joe Conway (m...@joeconway.com) wrote: >> On 09/24/2015 10:08 AM, Stephen Frost wrote: >>> debbugs does most of the above by default, no programming needed... I'm >>> sure we could get it to integrate with the commitfest and have a git >>> commit ho

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

* Joe Conway (m...@joeconway.com) wrote: > On 09/24/2015 10:08 AM, Stephen Frost wrote: > > debbugs does most of the above by default, no programming needed... I'm > > sure we could get it to integrate with the commitfest and have a git > > commit hook which sends the appropriate email to it also.

Re: [HACKERS] DBT-3 with SF=20 got failed

On 09/24/2015 07:04 PM, Tom Lane wrote: Tomas Vondra writes: But what about computing the number of expected batches, but always start executing assuming no batching? And only if we actually fill work_mem, we start batching and use the expected number of batches? Hmm. You would likely be do

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

I promised myself I'd stay out of this discussion, but ... Josh Berkus writes: > I know we're big on reinventing the wheel here, but it would really be a > better idea to use an established product than starting over from > scratch. Writing a bug tracker is a lot of work and maintenance. Yeah; "

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/24/2015 10:08 AM, Stephen Frost wrote: > debbugs does most of the above by default, no programming needed... I'm > sure we could get it to integrate with the commitfest and have a git > commit hook which sends the appropriate email to it also. > > That the emacs folks are using it makes me

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

* Josh Berkus (j...@agliodbs.com) wrote: > I know we're big on reinventing the wheel here, but it would really be a > better idea to use an established product than starting over from > scratch. Writing a bug tracker is a lot of work and maintenance. I tend to agree. > > The two most common inter

Re: [HACKERS] DBT-3 with SF=20 got failed

Tomas Vondra writes: > But what about computing the number of expected batches, but always > start executing assuming no batching? And only if we actually fill > work_mem, we start batching and use the expected number of batches? Hmm. You would likely be doing the initial data load with a "too

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On Wed, Sep 23, 2015 at 12:24 AM, Syed, Rahila wrote: > Hello, > > Please find attached patch with bugs reported by Thom and Sawada-san solved. The regression test failed on my machine, so you need to update the regression test, I think. Regards, -- Fujii Masao -- Sent via pgsql-hackers mai

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/23/2015 10:25 PM, Thomas Munro wrote: > On Thu, Sep 24, 2015 at 1:31 PM, Joe Conway wrote: >> On 09/23/2015 05:21 PM, Thomas Munro wrote: >>> Do you think it would make any sense to consider evolving what we have >>> already? At the moment, we have a bug form, and when you submit it it >>>

Re: [HACKERS] jsonb_set array append hack?

>> For that matter, we should probably disallow NULL path elements also, shouldn't we? > I'd say yes. Well, here is the new `setPath` function with this modification. Is it what did you mean? non_integer_in_path2.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hack

Re: [HACKERS] multivariate statistics / patch v7

Hi, On 09/24/2015 06:43 PM, Josh Berkus wrote: Tomas, attached is v7 of the multivariate stats patch. The main improvement is major refactoring of the clausesel.c portion - splitting the awfully long spaghetti-style functions into smaller pieces, making it much more understandable etc. So pr

Re: [HACKERS] DBT-3 with SF=20 got failed

On 09/24/2015 05:18 PM, Tom Lane wrote: Robert Haas writes: Of course, if we can postpone sizing the hash table until after the input size is known, as you suggest, then that would be better still (but not back-patch material). AFAICS, it works that way today as long as the hash fits in mem

Re: [HACKERS] TEXT vs VARCHAR join qual push down diffrence, bug or expected?

Jeevan Chalke writes: > On Wed, Sep 23, 2015 at 10:15 PM, Tom Lane wrote: >> After a bit more thinking and experimentation, I propose the attached >> patch. > I had a look over the patch and reviewed it. It is in excellent state to > check-in. After further thought I decided that the base case

Re: [HACKERS] multivariate statistics / patch v7

Tomas, > attached is v7 of the multivariate stats patch. The main improvement is > major refactoring of the clausesel.c portion - splitting the awfully > long spaghetti-style functions into smaller pieces, making it much more > understandable etc. So presumably v7 handles varlena attributes as we

Re: [HACKERS] DBT-3 with SF=20 got failed

On 09/24/2015 05:09 PM, Robert Haas wrote: On Thu, Sep 24, 2015 at 9:49 AM, Tomas Vondra wrote: So while it does not introduce behavior change in this particular case (because it fails, as you point out), it introduces a behavior change in general - it simply triggers behavior that does not h

Re: [HACKERS] clearing opfuncid vs. parallel query

Robert Haas writes: > Also, it's not like this change couldn't be UN-done at a future point. > I mean, Tom didn't like the flag I added aesthetically, but if we > needed it, we could have it. Or we could engineer something else. For the record: that's true for the patch you just committed. But

Re: [HACKERS] clearing opfuncid vs. parallel query

Alvaro Herrera writes: > I think allowing an operator's implementation function to change would > be rather problematic, would it not? There's no way to know whether the > semantic changes to stored rules would make sense, not least because the > person running ALTER OPERATOR wouldn't know (== ha

Re: [HACKERS] clearing opfuncid vs. parallel query

Tom Lane wrote: > To my mind though, the lack of an ALTER OPERATOR SET FUNCTION command > is on par with our very limited ability to alter the contents of > an operator class. In principle it would be nice, but the practical > value is so small that it's not surprising it hasn't been done --- > a

Re: [HACKERS] clearing opfuncid vs. parallel query

On Thu, Sep 24, 2015 at 11:54 AM, Tom Lane wrote: > Andres Freund writes: >> On 2015-09-23 17:29:50 -0400, Robert Haas wrote: >>> Well, I can't vouch for what any human being on earth has thought >>> about over a twenty-year period. It's not intrinsically unreasonable >>> in my mind to want to a

Re: [HACKERS] clearing opfuncid vs. parallel query

Andres Freund writes: > On 2015-09-23 17:29:50 -0400, Robert Haas wrote: >> Well, I can't vouch for what any human being on earth has thought >> about over a twenty-year period. It's not intrinsically unreasonable >> in my mind to want to alter an operator to point at a different >> procedure. >

Re: [HACKERS] clearing opfuncid vs. parallel query

On Wed, Sep 23, 2015 at 7:25 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Sep 23, 2015 at 5:39 PM, Tom Lane wrote: >>> Yeah, though I think of that as a longer-term issue, ie we could clean it >>> up sometime later. > >> So, you're thinking of something as simple as the attached? > > Rig

Re: [HACKERS] clearing opfuncid vs. parallel query

On 2015-09-23 17:29:50 -0400, Robert Haas wrote: > Well, I can't vouch for what any human being on earth has thought > about over a twenty-year period. It's not intrinsically unreasonable > in my mind to want to alter an operator to point at a different > procedure. Wouldn't we use plan invalidat

Re: [HACKERS] [COMMITTERS] pgsql: Lower *_freeze_max_age minimum values.

Cc'ing -hackers. Andres Freund wrote: > On 2015-09-24 10:37:33 -0400, Tom Lane wrote: > > Andres Freund writes: > > Should this patch not have also touched the per-table limits in > > reloptions.c? > > Hm. I guess that'd make sense. It's not really related to the goal of > making it realistic t

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Thu, Sep 24, 2015 at 6:32 PM, Andres Freund wrote: > On 2015-09-15 20:16:10 +0300, YUriy Zhuravlev wrote: > > We will be tested. > > Did you have a chance to run some benchmarks? > Yes, we now have 60 physical cores intel server and we're running benchmarks on it. -- Alexander Korotkov P

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On 2015-09-15 20:16:10 +0300, YUriy Zhuravlev wrote: > We will be tested. Did you have a chance to run some benchmarks? Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] ON CONFLICT issues around whole row vars,

On 2015-09-19 18:40:14 -0700, Peter Geoghegan wrote: > > An actually trivial, although not all that pretty, fix is to simply > > accept wholerow references in fix_join_expr_mutator(), even if not in > > the targetlist. As far as I can see the problem right now really can > > only be hit for whole r

Re: [HACKERS] DBT-3 with SF=20 got failed

Robert Haas writes: > Of course, if we can postpone sizing the hash table until after the > input size is known, as you suggest, then that would be better still > (but not back-patch material). AFAICS, it works that way today as long as the hash fits in memory (ie, single-batch). We load into a

Re: [HACKERS] DBT-3 with SF=20 got failed

On Thu, Sep 24, 2015 at 9:49 AM, Tomas Vondra wrote: > So while it does not introduce behavior change in this particular case > (because it fails, as you point out), it introduces a behavior change in > general - it simply triggers behavior that does not happen below the limit. > Would we accept t

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/24/2015 10:28 AM, k...@rice.edu wrote: On Wed, Sep 23, 2015 at 04:33:33PM -0700, Josh Berkus wrote: On 09/23/2015 03:05 PM, Jim Nasby wrote: On 9/23/15 3:12 PM, Thomas Kellerer wrote: They also support Postgres as their backend (and you do find hints here and there that it is the recom

Re: [HACKERS] pg_resetxlog sentences

On Fri, Sep 18, 2015 at 1:58 AM, Euler Taveira wrote: > On 17-09-2015 00:25, Fujii Masao wrote: >> >> One relevant question is; why doesn't pg_controldata report >> newestCommitTs? >> > I thought about it while looking at the code but forgot to ask. AFAICS it is > an oversight. See attached patch.

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On Wed, Sep 23, 2015 at 04:33:33PM -0700, Josh Berkus wrote: > On 09/23/2015 03:05 PM, Jim Nasby wrote: > > On 9/23/15 3:12 PM, Thomas Kellerer wrote: > >> They also support Postgres as their backend (and you do find hints > >> here and > >> there > >> that it is the recommended open source DBMS fo

Re: [HACKERS] [COMMITTERS] pgsql: Add pages deleted from pending list to FSM

On Sat, Sep 19, 2015 at 5:20 AM, Jeff Janes wrote: > On Fri, Sep 18, 2015 at 6:27 AM, Tom Lane wrote: >> >> [ moving thread to -hackers ] >> >> Fujii Masao writes: >> > So autoanalyze still doesn't call IndexFreeSpaceMapVacuum(). >> > That is, only backend can clean the list in INSERT-only workl

Re: [HACKERS] DBT-3 with SF=20 got failed

On 09/24/2015 01:51 PM, Robert Haas wrote: On Thu, Sep 24, 2015 at 5:50 AM, Tomas Vondra wrote: I however quite dislike the dismissal of the possible impact. It should be the responsibility of the person introducing the change to show that no such impact actually exists, not just waving it of

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On Thu, Sep 24, 2015 at 1:25 AM, Thomas Munro wrote: > The two most common interactions could go something like this: > > 1. User enters bug report via form, creating an issue in NEW state > and creating a pgsql-bugs thread. Someone responds by email that this > is expected behaviour, not a bug,

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On Wed, Sep 23, 2015 at 12:24 AM, Syed, Rahila wrote: > Hello, > > Please find attached patch with bugs reported by Thom and Sawada-san solved. > >>* The progress of vacuum by autovacuum seems not to be displayed. > The progress is stored in shared variables during autovacuum. I guess the > reaso

Re: [HACKERS] 9.5: Can't connect with PGSSLMODE=require on Windows

On 23 September 2015 at 13:10, Michael Paquier wrote: > > > On Wed, Sep 23, 2015 at 2:15 AM, Robert Haas wrote: >> >> On Tue, Sep 22, 2015 at 11:23 AM, Andrew Dunstan >> wrote: >> > "git bisect" is your friend. >> >> Yeah, but finding someone who has a working Windows build environment >> and a

Re: [HACKERS] PATCH: use foreign keys to improve join estimates v1

Hi, Thanks for the review and time spent on reworking the patch! On 09/24/2015 07:41 AM, David Rowley wrote: On 23 September 2015 at 17:11, David Rowley mailto:david.row...@2ndquadrant.com>> wrote: find_foreign_key_clauses() should look for the longest match and return a Bitmap set of

Re: [HACKERS] DBT-3 with SF=20 got failed

On Thu, Sep 24, 2015 at 5:50 AM, Tomas Vondra wrote: > I however quite dislike the dismissal of the possible impact. It should be > the responsibility of the person introducing the change to show that no such > impact actually exists, not just waving it off as "unbased on any evidence" > when ther

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

* Thomas Kellerer (spam_ea...@gmx.net) wrote: > > And email integration for Jira is nonexistant. > > That is not true. We do have an email integration where customers can create > issues by sending an email to a specific "Jira Email" address. And as far as > I know this is a standard module from

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Josh Berkus wrote: > > When we discussed this 8 years ago, Debian said debbugs wasn't ready for > > anyone else to use. Has that changed? > > Emacs uses debbugs now, so there's at least one non-Debian user. Oh? Nice. debbugs matches up large

Re: [HACKERS] [Proposal] Table partition + join pushdown

Hello, KaiGai-san. Thank you for your comment, and sorry for late response. The attached patch is completely rewritten from previous patch[1], at your suggestion[2]. Please find attached. This patch contains following implementation, but I can't determine this is correct or wrong. 1. Cost es

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

On 24/09/15 22:41, Geoff Winkless wrote: On 24 September 2015 at 11:33, Gavin Flower >wrote: An example from a book on PostgreSQL server programming that I'm working through (Note that it is obviously awkward to write with gender pronouns when g

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

On 24 September 2015 at 11:33, Gavin Flower wrote: > An example from a book on PostgreSQL server programming that I'm working > through (Note that it is obviously awkward to write with gender pronouns > when gender is irrelevant, note the "he she" in one place and "he/she" in > another!): > >

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

An example from a book on PostgreSQL server programming that I'm working through (Note that it is obviously awkward to write with gender pronouns when gender is irrelevant, note the "he she" in one place and "he/she" in another!): "If the user is a superuser, then he she has permission to

Re: [HACKERS] DBT-3 with SF=20 got failed

Hi, On 09/23/2015 11:25 PM, Tom Lane wrote: Tomas Vondra writes: On 09/11/2015 07:16 PM, Robert Haas wrote: On Fri, Sep 11, 2015 at 1:12 PM, Tomas Vondra wrote: I'm arguing for fixing the existing bug, and then addressing the case of over-estimation separately, with proper analysis. Well

Re: [HACKERS] Calculage avg. width when operator = is missing

On Thu, Sep 24, 2015 at 12:30 AM, Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane wrote: > >> Personally I think Alvaro's position is unduly conservative: to the > extent > >> that plans change it'd likely be for the better. But I'm not excited > >> enough to fight hard about it. > > > I

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

On Fri, Sep 11, 2015 at 10:15 AM, Michael Paquier wrote: > On Fri, Sep 11, 2015 at 3:41 AM, Beena Emerson > wrote: >> Please find attached the WIP patch for the proposed feature. It is built >> based on the already discussed design. >> >> Changes made: >> - add new parameter "sync_file" to provi

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 24.09.2015 01:33, Josh Berkus wrote: On 09/23/2015 03:05 PM, Jim Nasby wrote: On 9/23/15 3:12 PM, Thomas Kellerer wrote: They also support Postgres as their backend (and you do find hints here and there that it is the recommended open source DBMS for them - but they don't explicitly state i

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 23.09.2015 20:43, Robert Haas wrote: On Wed, Sep 23, 2015 at 2:30 PM, Kam Lasater wrote: Thanks for the suggestion. However, an issue tracker is not a replacement for mailing list(s) and vice versa. They are both necessary for success. I venture to say that we are succeeding as it is, alt

Re: [HACKERS] TEXT vs VARCHAR join qual push down diffrence, bug or expected?

On Wed, Sep 23, 2015 at 10:15 PM, Tom Lane wrote: > I wrote: > > Hm ... actually, we probably need *both* types of changes if that's > > what we believe the state values mean. > > I too was confused with the state explanations from the code-comments which we have them now. With your explanation h