Re: [HACKERS] path toward faster partition pruning

On 25 March 2018 at 18:28, David Rowley wrote: > The attached delta applies on top of v39 plus delta1. Sorry, the attached should do this. Ignore the last attachment. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7

Re: [PROPOSAL] Shared Ispell dictionaries

Tomas Vondra writes: > FWIW this is where the view listing dictionaries loaded into shared > memory would be helpful - you'd at least know there's a dictionary, > wasting memory. Well, that's only because we failed to make the implementation transparent :-(. But

Re: [PROPOSAL] Shared Ispell dictionaries

Tomas Vondra writes: > On 3/24/18 9:56 PM, Tom Lane wrote: >> Also, the scheme for releasing the dictionary DSM during >> RemoveTSDictionaryById is uncertain and full of race conditions: >> the DROP might roll back later, or someone might come along and >> start

Re: Using base backup exclusion filters to reduce data transferred with pg_rewind

Stephen Frost writes: > I don't completely buy off on the argument that having these #define's > would make it easier for forks (we've had quite a few folks fork PG, but > how many of them have actually changed "base"?) and I'm on the fence > about if these will make our lives

Re: pgsql: Avoid premature free of pass-by-reference CALL arguments.

Andres Freund writes: > On 2018-02-10 18:37:17 +, Tom Lane wrote: > CALL ptest1(substring(random()::text, 1, 1)); -- ok, volatile arg > At first I was gosh darned confused, this really didn't seem likely to > be an LLVM induced failure. And it turns out it isn't. If the

Re: JIT compiling with LLVM v12.2

Thomas Munro wrote: > typos A dead line. -- Thomas Munro http://www.enterprisedb.com 0003-Remove-dead-code.patch Description: Binary data

Re: Using base backup exclusion filters to reduce data transferred with pg_rewind

Greetings, * Michael Paquier (mich...@paquier.xyz) wrote: > On Fri, Mar 23, 2018 at 01:38:38AM +0900, Fujii Masao wrote: > > Personally it looks very intrusive, so I'm feeling inclined to push > > the changes without that refactoring. I've been reading over the first couple of posted patches and

Re: Undesirable entries in typedefs list

On Sun, Mar 25, 2018 at 3:55 AM, Tom Lane wrote: > I noticed that doing pgindent with the current typedefs list available > from the buildfarm caused a lot of havoc in what had been stable code. > Looking into the reasons, it seems that: > > (1) "bool" is no longer listed as a

Re: Changing default value of wal_sync_method to open_datasync on Linux

From: Robert Haas I also said it would be worse on spinning disks. Also, Yoshimi Ichiyanagi did not find it to be true even on NVRAM. Yes, let me withdraw this proposal. I couldn't see any performance difference even with ext4 volume on a PCIe flash memory. Regards MauMau

Re: Faster inserts with mostly-monotonically increasing values

On Fri, Mar 23, 2018 at 8:27 PM, Pavan Deolasee wrote: >> >> >> I would probably just have a few regression lines that should be sure >> to exercise the code path and leave it at that. >> > > I changed the regression tests to include a few more scenarios, basically >

Re: [HACKERS] pgbench - allow to store select results into variables

Here is a v14, after yet another rebase, and some comments added to answer your new comments. Attached v15 is a simple rebase after Teodor push of new functions & operators in pgbench. Patch v16 is a rebase. -- Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml

Re: WIP: Covering + unique indexes.

On Sat, Mar 24, 2018 at 12:39 PM, Alexander Korotkov wrote: > +1, putting "nattributes" to argument of index_truncate_tuple() would > make this function way more universal. Great. > Originally that code was written by Teodor, but I also put my hands there. > In GIN

Re: Undesirable entries in typedefs list

On 2018-03-24 14:51:32 -0700, Peter Geoghegan wrote: > On Sat, Mar 24, 2018 at 1:36 PM, Andres Freund wrote: > > I've attached the difference between a objdump typedefs list roughly > > equivalent to what the buildfarm uses. There's no difference when not > > using llvm. > > >

Re: Undesirable entries in typedefs list

On Sat, Mar 24, 2018 at 1:36 PM, Andres Freund wrote: > I've attached the difference between a objdump typedefs list roughly > equivalent to what the buildfarm uses. There's no difference when not > using llvm. > > I'm a bit uncomfortable relying --dwarf-depth=3, with 3 being

Re: pgsql: Avoid premature free of pass-by-reference CALL arguments.

On 2018-02-10 18:37:17 +, Tom Lane wrote: > Avoid premature free of pass-by-reference CALL arguments. > src/test/regress/expected/create_procedure.out | 12 +++ > src/test/regress/sql/create_procedure.sql | 4 +++- > 3 files changed, 33 insertions(+), 11 deletions(-) There's a

Re: [PROPOSAL] Shared Ispell dictionaries

Arthur Zakirov writes: > [ v10 patch versions ] I took a quick look through this. I agree with the comments about mmap-ability not being something we should insist on now, and maybe not ever. However, in order to keep our options open, it seems like we should minimize

Re: Undesirable entries in typedefs list

On 2018-03-24 10:41:40 -0700, Andres Freund wrote: > I'm about to head out, but afterwards I'm going to check what the > typedefs collected actually are when LLVM is enabled. It's indeed from llvm: <3><5201>: Abbrev Number: 4 (DW_TAG_typedef) <5202> DW_AT_name: (indirect string,

Re: Why does load_external_function() return PGFunction?

On 2018-02-06 15:43:29 -0500, Tom Lane wrote: > Andres Freund writes: > > We've several callers to load_external_function() that do not use the > > returned value as a PGFunction. I'd vote for changing the return type to > > void * and have fmgr.c cast it to PGFunction after

Re: WIP: Covering + unique indexes.

On Sat, Mar 24, 2018 at 5:21 AM, Peter Geoghegan wrote: > On Thu, Mar 22, 2018 at 8:23 AM, Alexander Korotkov > wrote: > >> * There is minor formatting issue in this part of code. Some spaces > need > >> to be replaced with tabs. > >> +IndexTuple > >>

Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently

Claudio Freire writes: > [ 0001-Vacuum-Update-FSM-more-frequently-v9.patch ] I hadn't paid any attention to this patch previously, so maybe I'm missing something ... but this sure seems like a very bizarre approach to the problem. If the idea is to fix the FSM's upper

Proposal: http2 wire format

Hello hackers, I’d like to propose the implementation of new wire protocol using http2 framing. It appears to me that http2 solves many of the issues on the TODO list under “Wire Protocol Changes / v4 Protocol,“ without any obvious downsides. The implementation I have in mind has zero

Re: [HACKERS] MERGE SQL Statement for PG11

On Sat, Mar 24, 2018 at 5:27 AM, Robert Haas wrote: > If it's possible to identify the two OIDs that are supposed to match > and cross-check that the OIDs are the same, then we could just bomb > out with an error if they aren't. That's not lovely, and is basically > a

Re: Undesirable entries in typedefs list

Hi, On 2018-03-24 13:34:45 -0400, Tom Lane wrote: > That was my first thought as well, since this seems to have changed > quite recently. I don't think it's a bad idea to be collecting typedefs > from something that compiles that code, because otherwise our own > typedefs in that area won't be

Re: Undesirable entries in typedefs list

Andres Freund writes: > On 2018-03-24 13:25:34 -0400, Tom Lane wrote: >> (2) "abs", "boolean", "iterator", "other", "pointer", "reference", >> "string", and "type" all now are listed as typedef names. >> >> It's probably okay to treat "boolean" as a typedef, but all those

Re: Undesirable entries in typedefs list

Hi, On 2018-03-24 13:25:34 -0400, Tom Lane wrote: > (2) "abs", "boolean", "iterator", "other", "pointer", "reference", > "string", and "type" all now are listed as typedef names. > > It's probably okay to treat "boolean" as a typedef, but all those others > are complete disasters. Anyone know

Undesirable entries in typedefs list

I noticed that doing pgindent with the current typedefs list available from the buildfarm caused a lot of havoc in what had been stable code. Looking into the reasons, it seems that: (1) "bool" is no longer listed as a typedef name (probably because stdbool.h makes it a macro instead); (2)

Re: [HACKERS] MERGE SQL Statement for PG11

On Fri, Mar 23, 2018 at 11:52 PM, Pavan Deolasee wrote: > A quick gdb tracing shows that the CTE itself is assigned plan_id 1 and the > SubPlan then gets plan_id 2. I can investigate further, but given that we > see a similar behaviour with regular UPDATE, I don't think

Re: [PATCH] Verify Checksums during Basebackups

Hi, Am Freitag, den 23.03.2018, 17:43 +0100 schrieb Michael Banck: > Am Freitag, den 23.03.2018, 10:54 -0400 schrieb David Steele: > > In my experience actual block errors are relatively rare, so there > > aren't likely to be more than a few in a file. More common are > > overwritten or

Re: Running Installcheck remotely

Kapil Sharma writes: > Is it possible to run installcheck (pg_regress) tests from a remote host ? I think if you set PGHOST and other relevant libpq environment variables, an installcheck run will connect where they specify. The hard part would be making sure that (a)

Re: PL/pgSQL nested CALL with transactions

On 3/22/18 11:50, Tomas Vondra wrote: > 1) plpgsql.sgml > > The new paragraph talks about "intervening command" - I've been unsure > what that refers too, until I read the comment for ExecutCallStmt(), > which explains this as CALL -> SELECT -> CALL. Perhaps we should add > that to the sgml docs

Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()

On Sat, Mar 24, 2018 at 12:37:21PM +, Simon Riggs wrote: > If you have anything further to say, make it a formal complaint > offlist so we can discuss engineering here. Commit fest operations and patch reviews concern the community. There is always something to learn for other people

Re: PQHost() undefined behavior if connecting string contains both host and hostaddr types

On Sat, Mar 24, 2018 at 01:49:28AM +1100, Haribabu Kommi wrote: > Here I attached the updated patch that returns either the connected > host/hostaddr > or NULL in case if the connection is not established. > > I removed the returning default host details, because the default host > details are

Re: [HACKERS] why not parallel seq scan for slow functions

On Sat, Mar 24, 2018 at 8:41 AM, Robert Haas wrote: > On Fri, Mar 23, 2018 at 12:12 AM, Amit Kapila wrote: >> Yeah, sometimes that kind of stuff change performance characteristics, >> but I think what is going on here is that create_projection_plan

Re: Re: csv format for psql

2018-03-24 10:06 GMT+01:00 Fabien COELHO : > > Hello Pavel, > > I'm suggesting to add \csv which would behave like \H to toggle CSV mode so as to improve this situation, with a caveat which is that toggling back \csv would have forgotted the previous

Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()

On 24 March 2018 at 12:19, Robert Haas wrote: > On Sat, Mar 24, 2018 at 8:11 AM, Simon Riggs wrote: >> On 24 March 2018 at 11:58, Robert Haas wrote: >>> On Sat, Mar 24, 2018 at 7:42 AM, Simon Riggs

Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()

On Sat, Mar 24, 2018 at 5:28 PM, Robert Haas wrote: > > This is a patch about which multiple people have expressed concerns. > You're trying to jam a heavily redesigned version in at the last > minute without adequate review. Please don't do that. > > TBH this is not a

Re: [HACKERS] MERGE SQL Statement for PG11

On Sat, Mar 24, 2018 at 8:16 AM, Robert Haas wrote: > On Thu, Mar 22, 2018 at 7:13 PM, Peter Geoghegan wrote: >> While I think this this particular HINT buglet is pretty harmless, I >> continue to be concerned about the unintended consequences of having >>

Re: [HACKERS] MERGE SQL Statement for PG11

On 24 March 2018 at 12:16, Robert Haas wrote: > On Thu, Mar 22, 2018 at 7:13 PM, Peter Geoghegan wrote: >> While I think this this particular HINT buglet is pretty harmless, I >> continue to be concerned about the unintended consequences of having >> multiple

Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()

On Sat, Mar 24, 2018 at 8:11 AM, Simon Riggs wrote: > On 24 March 2018 at 11:58, Robert Haas wrote: >> On Sat, Mar 24, 2018 at 7:42 AM, Simon Riggs wrote: >>> I suggest we focus on the engineering. I've not discussed this

Re: [HACKERS] MERGE SQL Statement for PG11

On Thu, Mar 22, 2018 at 7:13 PM, Peter Geoghegan wrote: > While I think this this particular HINT buglet is pretty harmless, I > continue to be concerned about the unintended consequences of having > multiple RTEs for MERGE's target table. Each RTE comes from a > different lookup

Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()

On 24 March 2018 at 11:58, Robert Haas wrote: > On Sat, Mar 24, 2018 at 7:42 AM, Simon Riggs wrote: >> I suggest we focus on the engineering. I've not discussed this patch >> with Pavan offline. > > Well then proposing to commit moments after it's

Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()

On Sat, Mar 24, 2018 at 7:42 AM, Simon Riggs wrote: > I suggest we focus on the engineering. I've not discussed this patch > with Pavan offline. Well then proposing to commit moments after it's been posted is ridiculous. That's exactly the opposite of "focusing on the

Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()

I suggest we focus on the engineering. I've not discussed this patch with Pavan offline. On 23 March 2018 at 23:32, Michael Paquier wrote: > On Fri, Mar 23, 2018 at 11:06:48AM +, Simon Riggs wrote: >> Your assumption that I would commit a new patch that was 29 mins old

Re: JIT compiling with LLVM v12.2

Hi Andres, I spotted a couple of typos and some very minor coding details -- see please see attached. -- Thomas Munro http://www.enterprisedb.com 0001-Correct-some-minor-typos-in-the-new-JIT-code.patch Description: Binary data 0002-Minor-code-cleanup-for-llvmjit_wrap.cpp.patch Description:

Re: pgbench - test whether a variable exists

While investigating moving pgbench expressions to fe_utils so that they can be shared with psql (\if ..., \let ?), I figure out that psql's \if has a syntax to test whether a variable exists, which is not yet available to pgbench. This patch adds the same syntax to pgbench expression so

Re: pgbench randomness initialization

Patch isn't applyed cleanly anymore. Indeed. Here is a rebase. All pgbench patches conflict about test cases. Patch v12, yet another rebase. -- Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml index d52d324..41d9030 100644 ---

Re: Re: csv format for psql

Hello Pavel, I'm suggesting to add \csv which would behave like \H to toggle CSV mode so as to improve this situation, with a caveat which is that toggling back \csv would have forgotted the previous settings (just like \H does, though, so would for instance reset to aligned

Re: Running Installcheck remotely

On Sat, Mar 24, 2018 at 01:02:47AM -0700, Kapil Sharma wrote: > Is it possible to run installcheck (pg_regress) tests from a remote > host? You can use EXTRA_REGRESS_OPTS to pass a custom set of options to pg_regress, say: EXTRA_REGRESS_OPTS='--host=remote_ip' make installcheck You can use as

Re: Re: csv format for psql

minor fix > all is working now [pavel@nemesis postgresql]$ psql --csv -F ';' -c "table foo" postgres a;b;c 3;4;Nazdar 3;4;Nazdar [pavel@nemesis postgresql]$ psql -F ';' --csv -c "table foo" postgres a;b;c 3;4;Nazdar 3;4;Nazdar [pavel@nemesis postgresql]$ psql --csv -c "table foo" postgres

Re: Re: csv format for psql

2018-03-24 8:24 GMT+01:00 Pavel Stehule : > > > 2018-03-24 8:15 GMT+01:00 Fabien COELHO : > >> >> Hello Pavel, >> >> The patch adds a simple way to generate csv output from "psql" queries, much simpler than playing around with COPY or \copy. It

Running Installcheck remotely

Hi, Is it possible to run installcheck (pg_regress) tests from a remote host ? Thanks, Kapil.

Re: Re: csv format for psql

2018-03-24 8:15 GMT+01:00 Fabien COELHO : > > Hello Pavel, > > The patch adds a simple way to generate csv output from "psql" queries, >>> much simpler than playing around with COPY or \copy. It allows to >>> generate >>> a clean CSV dump from something as short as: >>> >>>

Re: Re: csv format for psql

Hello Pavel, The patch adds a simple way to generate csv output from "psql" queries, much simpler than playing around with COPY or \copy. It allows to generate a clean CSV dump from something as short as: sh> psql --csv -c 'TABLE foo' > foo.csv Documentation is clear. Test cover a

Re: [HACKERS] MERGE SQL Statement for PG11

On Sat, Mar 24, 2018 at 1:36 AM, Peter Geoghegan wrote: > > Fair enough. Attached patch shows what I'm on about. This should be > applied on top of 0001_merge_v23e_onconflict_work.patch + > 0002_merge_v23e_main.patch. I'm not expecting an authorship credit for > posting this patch.

Re: [HACKERS] MERGE SQL Statement for PG11

On Fri, Mar 23, 2018 at 11:15 PM, Peter Geoghegan wrote: > I agree that this is very similar, as far as the RTEs go. What is > dissimilar is the fact that there is hard-coded knowledge of both > through parsing, planning, and execution. It's everything, taken > together. > >

Re: [HACKERS] MERGE SQL Statement for PG11

On Fri, Mar 23, 2018 at 4:56 AM, Pavan Deolasee wrote: > postgres=# insert into target as t select sid from source s join target t on > t.ttid = s.sid; > ERROR: column t.ttid does not exist > LINE 1: ...rget as t select sid from source join target t on t.ttid = s... >