Re: [HACKERS] psql: add \pset true/false

On Thu, Nov 12, 2015 at 1:04 PM, David G. Johnston < david.g.johns...@gmail.com> wrote: > On Thu, Oct 29, 2015 at 6:50 AM, Tom Lane wrote: > >> Marko Tiikkaja writes: >> > On 10/29/15 11:51 AM, Daniel Verite wrote: >> >> Personally I think it would be worth

Re: [HACKERS] psql: add \pset true/false

On Thu, Oct 29, 2015 at 6:50 AM, Tom Lane wrote: > Marko Tiikkaja writes: > > On 10/29/15 11:51 AM, Daniel Verite wrote: > >> Personally I think it would be worth having, but how about > >> booleans inside ROW() or composite types ? > > > There's not enough

Re: [HACKERS] psql: add \pset true/false

On 10/29/15 9:50 AM, Tom Lane wrote: > The really key argument that hasn't been addressed here is why does such > a behavior belong in psql, rather than elsewhere? Because it is the job of the client to mangle the data so that it suits the purposes of the client. What comes over the wire is part

Re: [HACKERS] psql: add \pset true/false

Matthijs van der Vleuten wrote: > -1 for changing boolout(). It will break anything that receives > boolean values from the server. Not if the default output is still 't' or 'f' like now. Nobody seems to suggest a gratuitous compatibility break. > How a client is going to display

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

Dean Rasheed writes: > These results are based on the attached, updated patch which includes > a few minor improvements. I started to look at this patch, and was immediately bemused by the comment in estimate_ln_weight: /* * 0.9 <= var <= 1.1

Re: [HACKERS] psql: add \pset true/false

Peter Eisentraut writes: > Plus we already have \pset numericlocale as a similar feature in psql. But \pset numericlocale is also a crock. It doesn't affect COPY output for instance, and its ability to identify which data types it should apply to is really shaky. And it's

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

On Wed, Nov 11, 2015 at 6:50 AM, Ildus Kurbangaliev wrote: > Attached a new version of the patch that moves SLRU tranches and LWLocks to > SLRU control structs. > > `buffer_locks` field now contains LWLocks itself, so we have some economy of > the memory here.

Re: [HACKERS] psql: add \pset true/false

On Thu, Oct 29, 2015 at 5:28 AM, Matthijs van der Vleuten wrote: > I have had exactly this situation a week ago. I was testing the output of > an algorithm that is supposed to have exactly one true value per input id. > ​If this is particularly important I would add something

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

Robert and Kaigai-san, Sorry, I sent in an unfinished email. On 2015/11/12 15:30, Kouhei Kaigai wrote: On 2015/11/12 2:53, Robert Haas wrote: On Sun, Nov 8, 2015 at 11:13 PM, Etsuro Fujita wrote: To test this change, I think we should update the postgres_fdw

Re: [HACKERS] Minor comment improvement to create_foreignscan_plan

On 2015/11/10 3:53, Robert Haas wrote: On Mon, Nov 9, 2015 at 5:34 AM, Etsuro Fujita wrote: Here is a small patch to update an comment in create_foreignscan_plan; add fdw_recheck_quals to the list of expressions that need the replace_nestloop_params processing. I

Re: [HACKERS] pglogical_output - a general purpose logical decoding output plugin

On 2015/11/02 23:36, Craig Ringer wrote: > On 2 November 2015 at 20:17, Craig Ringer wrote: >> Hi all >> >> I'd like to submit pglogical_output for inclusion in the 9.6 series as >> a contrib. > > Here's the protocol documentation discussed in the README. It's > asciidoc

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

wrote: > > More knowledgeable people are sure to reply in more detail! > > However, they would probably appreciate it if you can run with 9.4.5 > (the latest released version). Running it with the beta of 9.5 would be > a bonus! > > Note that I don't know

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

wrote: >> >> We guessed the cause of this error would be in the cost model of Postgres, >> and investigated the source code of optimizer, and we found the cause of >> this problem. It was in the index cost estimation process. On scanning >> inner table, if loop count is

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

wrote: >> >> - cost parameter calibration: random_page_cost = 92.89 >> > > This demands some explanation and raises question of value of seq_page_cost > parameter -- I don't see anything about it your mail. seq_page_cost was set to 1.0 (default), and I

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

On Thu, Oct 29, 2015 at 11:16 PM, Fujii Masao wrote: > On Thu, Oct 22, 2015 at 12:47 AM, Masahiko Sawada > wrote: >> On Tue, Oct 20, 2015 at 8:10 PM, Beena Emerson >> wrote: >>> >>> On Mon, Oct 19, 2015 at 8:47 PM,

[HACKERS] Generalizing SortSupport for text to work with char(n), bytea, and alternative opclasses

We lack SortSupport for many character-like-type cases. In full, the cases within the core system are: * char(n) opfamily (bpchar_ops). * text_pattern_ops opfamily (includes text and varchar "pattern" opclasses, which are generally recommended for accelerating LIKE operator queries). *

Re: [HACKERS] Proposing COPY .. WITH PERMISSIVE

On Sat, Oct 3, 2015 at 1:43 PM, dinesh kumar wrote: > We can also use "PROGRAM 'cat > Output.csv' " to achieve this "NO READ > ACCESS", since the program is always running as a instance owner. > Let me know your inputs and thoughts. That's one way. And as PROGRAM presents the advantage to open

[HACKERS] LLVM miscompiles numeric.c access to short numeric var headers

I've been using LLVM's sanitizers and asan turned up a new bit of compiler behaviour that I hadn't had before. I don't see it in 3.7 or before, only in their HEAD so I don't know if it's a bug or intentional. In numeric.c we have the short numeric headers that have one uint16 (in addition to the

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On 11 November 2015 at 09:22, Thomas Munro wrote: > 1. Reader waits with exposed LSNs, as Heikki suggests. This is what > BerkeleyDB does in "read-your-writes" mode. It means that application > developers have the responsibility for correctly identifying

Re: [HACKERS] CustomScan support on readfuncs.c

On Mon, Nov 9, 2015 at 9:46 PM, Kouhei Kaigai wrote: > The attached main patch (custom-scan-on-readfuncs.v3.patch) once > removes TextOutCustomScan, thus all the serialized tokens become > known to the core backend, and add _readCustomScan() at readfuncs.c. > It deserializes

Re: [HACKERS] [DESIGN] ParallelAppend

> On 2015/11/12 14:09, 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 in the background worker context? > > > > The commit f0661c4e8c44c0ec7acd4ea7c82e85b265447398 added > >

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

Horiguchi-san, On 2015/11/12 16:10, Kyotaro HORIGUCHI wrote: I really don't see why you're fighting on this point. Making this a generic feature will require only a few extra lines of code for FDW authors. If this were going to cause some great inconvenience for FDW authors, then I'd agree it

Re: [HACKERS] psql: add \pset true/false

On Thu, Oct 29, 2015 at 10:50 PM, Tom Lane wrote: > Marko Tiikkaja writes: >> On 10/29/15 11:51 AM, Daniel Verite wrote: >>> Personally I think it would be worth having, but how about >>> booleans inside ROW() or composite types ? > >> There's not enough

Re: [HACKERS] CustomScan support on readfuncs.c

> On Mon, Nov 9, 2015 at 9:46 PM, Kouhei Kaigai wrote: > > The attached main patch (custom-scan-on-readfuncs.v3.patch) once > > removes TextOutCustomScan, thus all the serialized tokens become > > known to the core backend, and add _readCustomScan() at readfuncs.c. > > It

Re: [HACKERS] psql: add \pset true/false

On 11/12/15 1:50 PM, Michael Paquier wrote: FWIW, I am -1 on the concept of enforcing output values for particular datatypes because that's not the job of psql In my view, the job of psql is to make working with a postgres database easy for us human beings. That means (among other things)

Re: CustomScan in a larger structure (RE: [HACKERS] CustomScan support on readfuncs.c)

> > On Wed, Nov 11, 2015 at 3:29 PM, Andres Freund wrote: > > > On 2015-11-11 14:59:33 -0500, Robert Haas wrote: > > >> I don't see this as being a particularly good idea. The same issue > > >> exists for FDWs, and we're just living with it in that case. > > > > > > It's

Re: [HACKERS] checkpointer continuous flushing

On Wed, Nov 11, 2015 at 1:08 PM, Andres Freund wrote: > > On 2015-09-10 17:15:26 +0200, Fabien COELHO wrote: > > Here is a v13, which is just a rebase after 1aba62ec. > > > 3) I found that latency wasn't improved much for workloads that are >significantly bigger than

Re: [HACKERS] Parallel Seq Scan

On Thu, Nov 12, 2015 at 10:39 PM, Amit Kapila wrote: > The number of shared buffers hit could be different across different runs > because the read sequence of parallel workers can't be guaranteed, also > I don't think same is even guaranteed for Seq Scan node, The

Re: [HACKERS] CustomScan support on readfuncs.c

On Thu, Nov 12, 2015 at 7:59 AM, Kouhei Kaigai wrote: >> On Mon, Nov 9, 2015 at 9:46 PM, Kouhei Kaigai wrote: >> > The attached main patch (custom-scan-on-readfuncs.v3.patch) once >> > removes TextOutCustomScan, thus all the serialized tokens become >>

Re: [HACKERS] Multixid hindsight design

On Mon, Nov 9, 2015 at 9:57 PM, Craig Ringer wrote: > On 10 November 2015 at 02:26, Robert Haas wrote: >>> I'd like to see, say, python and the 'unittest' module added, and >>> to see acceptance of tests using psycopg2 to stream and decode WAL >>>

Re: [HACKERS] Documentation tweak for row-valued expressions and null

On Tue, Nov 10, 2015 at 11:10 AM, Jim Nasby wrote: > On 7/26/15 8:40 PM, Thomas Munro wrote: >> >> I wonder if it might be worth adding a tiny note to the manual to >> point out that the special logic for " IS [ NOT >> ] NULL" doesn't apply anywhere else that we handle

Re: [HACKERS] CustomScan support on readfuncs.c

> On Thu, Nov 12, 2015 at 7:59 AM, Kouhei Kaigai wrote: > >> On Mon, Nov 9, 2015 at 9:46 PM, Kouhei Kaigai wrote: > >> > The attached main patch (custom-scan-on-readfuncs.v3.patch) once > >> > removes TextOutCustomScan, thus all the serialized tokens

Re: [HACKERS] checkpointer continuous flushing

Hello Andres, And here's v14. It's not something entirely ready. I'm going to have a careful look at it. A lot of details have changed, I unfortunately don't remember them all. But there are more important things than the details of the patch. I've played *a lot* with this patch. I found

Re: [HACKERS] psql: add \pset true/false

On Fri, 30 Oct 2015 at 00:51 Tom Lane wrote: > The really key argument that hasn't been addressed here is why does such > a behavior belong in psql, rather than elsewhere? Surely legibility > problems aren't unique to psql users. Moreover, there are exactly > parallel

Re: [HACKERS] Dangling Client Backend Process

On Wed, Nov 11, 2015 at 1:55 AM, Michael Paquier wrote: > On Wed, Nov 4, 2015 at 2:18 AM, Robert Haas wrote: >> The second conclusion does not appear to be correct. parseInput() >> will call pqParseInput3() or pqParseInput2(), either of which will >> handle an error as

Re: [HACKERS] eXtensible Transaction Manager API

On Mon, Nov 9, 2015 at 2:47 PM, Simon Riggs wrote: > On 9 November 2015 at 18:46, Robert Haas wrote: >> > I am aware of the fact >> > that by definition PREPARE TRANSACTION ensures that a transaction will >> > be committed with COMMIT PREPARED, just

Re: [HACKERS] LLVM miscompiles numeric.c access to short numeric var headers

Greg Stark writes: > In numeric.c we have the short numeric headers that have one uint16 > (in addition to the varlena header) followed by digits. When compiling > with -O2 on x86-64 LLVM now seems to use a 4-byte access. Either that's a reportable compiler bug, or someplace

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On Fri, Nov 13, 2015 at 1:16 AM, Simon Riggs wrote: > On 11 November 2015 at 09:22, Thomas Munro > wrote: > > >> 1. Reader waits with exposed LSNs, as Heikki suggests. This is what >> BerkeleyDB does in "read-your-writes" mode. It means

Re: [HACKERS] checkpointer continuous flushing

Basically yes, I'm suggesting a mutex in the vdf struct. I can't see that being ok. I mean what would that thing even do? VFD isn't shared between processes, and if we get a smgr flush we have to apply it, or risk breaking other things. Probably something is eluding my comprehension:-) My

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

Hello, I also uncertain about what exactly is the blocker.. At Fri, 13 Nov 2015 02:31:53 +, Kouhei Kaigai wrote in <9a28c8860f777e439aa12e8aea7694f80116f...@bpxm15gp.gisp.nec.co.jp> > > Sorry, my explanation was not enough. The reason for that is that in > > the above

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

> -Original Message- > From: Etsuro Fujita [mailto:fujita.ets...@lab.ntt.co.jp] > Sent: Thursday, November 12, 2015 6:54 PM > To: Kaigai Kouhei(海外 浩平); Robert Haas > Cc: Tom Lane; Kyotaro HORIGUCHI; pgsql-hackers@postgresql.org; Shigeru Hanada > Subject: Re: [HACKERS] Foreign join pushdown

Re: [HACKERS] Parallel Seq Scan

On Thu, Nov 12, 2015 at 9:05 PM, Thom Brown wrote: > > On 12 November 2015 at 15:23, Amit Kapila wrote: > > On Wed, Nov 11, 2015 at 11:29 PM, Pavel Stehule > > wrote: > >> > >> Hi > >> > >> I have a first query > >> > >> I

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

On Fri, Nov 13, 2015 at 4:48 AM, Masahiko Sawada wrote: > > > Thank you for reviewing the patch. > > I changed the patch so that the visibility map become the page info > map, in source code and documentation. > One thing to notice is that this almost doubles the patch

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

Hello, At Fri, 13 Nov 2015 09:07:01 +0900, Masahiko Sawada wrote in > On Thu, Oct 29, 2015 at 11:16 PM, Fujii Masao wrote: > > On Thu, Oct 22, 2015 at 12:47 AM, Masahiko Sawada

Re: [HACKERS] LLVM miscompiles numeric.c access to short numeric var headers

Greg Stark writes: > On Thu, Nov 12, 2015 at 2:39 PM, Tom Lane wrote: >> Either that's a reportable compiler bug, or someplace nearby we've >> casted the pointer to something that would require a 4-byte struct. >> I'm not sure which code you're looking at

Re: [HACKERS] Parallel Seq Scan

On Wed, Nov 11, 2015 at 11:29 PM, Pavel Stehule wrote: > > Hi > > I have a first query > > I looked on EXPLAIN ANALYZE output and the numbers of filtered rows are differen > Thanks for the report. The reason for this problem is that instrumentation information from

Re: [HACKERS] Parallel Seq Scan

On 12 November 2015 at 15:23, Amit Kapila wrote: > On Wed, Nov 11, 2015 at 11:29 PM, Pavel Stehule > wrote: >> >> Hi >> >> I have a first query >> >> I looked on EXPLAIN ANALYZE output and the numbers of filtered rows are >> differen >> > >

Re: [HACKERS] LLVM miscompiles numeric.c access to short numeric var headers

On Thu, Nov 12, 2015 at 2:39 PM, Tom Lane wrote: > Either that's a reportable compiler bug, or someplace nearby we've > casted the pointer to something that would require a 4-byte struct. > I'm not sure which code you're looking at exactly, but maybe we're > using "union

Re: [HACKERS] checkpointer continuous flushing

Hi, On 2015-11-12 15:31:41 +0100, Fabien COELHO wrote: > >A lot of details have changed, I unfortunately don't remember them all. > >But there are more important things than the details of the patch. > > > >I've played *a lot* with this patch. I found a bunch of issues: > > > >1) The

Re: [HACKERS] psql: add \pset true/false

On 10/28/2015 10:03 AM, Marko Tiikkaja wrote: > Hello hello, > > Since the default t/f output for booleans is not very user friendly, > attached is a patch which enables you to do for example the following: > > =# \pset true TRUE > Boolean TRUE display is "TRUE". > =# \pset false FALSE > Boolean

Re: [HACKERS] checkpointer continuous flushing

Hello, Basically yes, I'm suggesting a mutex in the vdf struct. I can't see that being ok. I mean what would that thing even do? VFD isn't shared between processes, and if we get a smgr flush we have to apply it, or risk breaking other things. Probably something is eluding my

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On Fri, Nov 13, 2015 at 1:16 AM, Simon Riggs wrote: > On 11 November 2015 at 09:22, Thomas Munro > wrote: > > >> 1. Reader waits with exposed LSNs, as Heikki suggests. This is what >> BerkeleyDB does in "read-your-writes" mode. It means

Re: [HACKERS] Proposing COPY .. WITH PERMISSIVE

On Thu, Nov 12, 2015 at 4:35 AM, Michael Paquier wrote: > On Sat, Oct 3, 2015 at 1:43 PM, dinesh kumar wrote: > > We can also use "PROGRAM 'cat > Output.csv' " to achieve this "NO READ > > ACCESS", since the program is always running as a instance owner. > > Let me

Re: [HACKERS] psql: add \pset true/false

2015-11-12 17:41 GMT+01:00 Matthijs van der Vleuten : > > On 12 Nov 2015, at 14:21, Brendan Jurd wrote: > > On Fri, 30 Oct 2015 at 00:51 Tom Lane wrote: > >> The really key argument that hasn't been addressed here is why does such >> a

Re: [HACKERS] checkpointer continuous flushing

On 2015-11-12 17:44:40 +0100, Fabien COELHO wrote: > > >>To fix it, ITSM that it is enough to hold a "do not close lock" on the file > >>while a flush is in progress (a short time) that would prevent mdclose to do > >>its stuff. > > > >Could you expand a bit more on this? You're suggesting

Re: [HACKERS] psql: add \pset true/false

> On 12 Nov 2015, at 14:21, Brendan Jurd wrote: > > On Fri, 30 Oct 2015 at 00:51 Tom Lane > wrote: > The really key argument that hasn't been addressed here is why does such > a behavior belong in psql, rather than elsewhere?

Re: [HACKERS] psql: add \pset true/false

On 11/12/2015 05:41 PM, Matthijs van der Vleuten wrote: > >> On 12 Nov 2015, at 14:21, Brendan Jurd wrote: >> >> On Fri, 30 Oct 2015 at 00:51 Tom Lane > > wrote: >> The really key argument that hasn't been addressed here is why

Re: [HACKERS] LLVM miscompiles numeric.c access to short numeric var headers

On Thu, Nov 12, 2015 at 3:51 PM, Tom Lane wrote: > Meh. The palloc to create an aligned array of digits would eat up > any possible performance win --- it'd be just about as expensive > as the existing unpack operation. I suppose we would only need to palloc the digits if we

Re: [HACKERS] LLVM miscompiles numeric.c access to short numeric var headers

Greg Stark writes: > On Thu, Nov 12, 2015 at 3:51 PM, Tom Lane wrote: >> I think we could fix the immediate issue by redeclaring numeric >> headers as arrays of (u)int16 rather than structs. I'm not >> very excited about the packed-header case. > That would

Re: [HACKERS] checkpointer continuous flushing

To fix it, ITSM that it is enough to hold a "do not close lock" on the file while a flush is in progress (a short time) that would prevent mdclose to do its stuff. Could you expand a bit more on this? You're suggesting something like a boolean in the vfd struct? Basically yes, I'm

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

On Mon, Nov 9, 2015 at 2:42 AM, Simon Riggs wrote: > On 9 November 2015 at 10:08, wrote: >> >> >> We guessed the cause of this error would be in the cost model of Postgres, >> and investigated the source code of optimizer, and we found the