Re: [HACKERS] pg_waldump's inclusion of backend headers is a mess

You may want to name the new headers dedicated to WAL records with _xlog.h as suffix though, like gin_xlog.h instead of ginxlog.h. Should not it be more consistent to use "*_wal.h", after all these efforts to move "xlog" to "wal" everywhere? -- Fabien. -- Sent via pgsql-hackers mailing

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

Hello Corey, If I can find some simple mnemonic for "," vs "@" for being executed vs ignored, I could live with that, but nothing obvious comes to my mind. @in't gonna execute it? Hmmm... This is too much of an Americanism, IMHO. I'm here all week, try the veal. Sorry, syntax error,

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

Hi, On 18 November 2016 at 08:18, Craig Ringer wrote: >At this point I doubt I'll be able to >get update it again in time for v10, so anyone who wants to adopt it >is welcome. I am interested in pipeline/batch support for ECPG, and found this thread. I updated Craig's patch [1] to apply

Re: [HACKERS] Documentation improvements for partitioning

On 2017/02/13 14:21, Amit Langote wrote: > On 2017/02/10 19:19, Simon Riggs wrote: >> On 10 February 2017 at 08:18, Amit Langote >> wrote: >> >>> I agree that getting the proposed documentation changes committed would be >>> a step ahead. >> >> Committed. I tested

Re: [HACKERS] Proposal : Parallel Merge Join

On Wed, Jan 4, 2017 at 9:27 PM, Dilip Kumar wrote: > On Wed, Jan 4, 2017 at 12:02 PM, Amit Kapila wrote: >> 3. >> + /* >> + * See comments in try_partial_nestloop_path(). >> + */ >> >> This same code exists in try_partial_nestloop_path() and >>

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On Tue, Feb 14, 2017 at 12:56 PM, Michael Paquier wrote: > This way you can monitor the time it takes to build > completely each index, including its . You can ignore the terms "including its" here. -- Michael -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

On Tue, Feb 14, 2017 at 3:19 PM, Seki, Eiji wrote: > This change will be useful for features that only reads rows that are visible > by all transactions and could not wait specific processes (VACUUM, ANALYZE, > etc...) for performance. Our company (Fujitsu) is

Re: [HACKERS] contrib modules and relkind check

On Tue, Feb 14, 2017 at 3:18 PM, Amit Langote wrote: > On 2017/02/13 14:59, Michael Paquier wrote: > I see, thanks for explaining. Implemented that in the attached, also > fixing the errcode. Please see if that's what you had in mind. Yes. That's it, the overall

[HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

Hi all, I propose the patch that adds a function GetOldestXminExtended that is like GetOldestXmin but can ignore arbitrary vacuum flags. And then, rewrite GetOldestXmin to use it. Note that this is done so as not to change the behavior of GetOldestXmin. This change will be useful for

Re: [HACKERS] contrib modules and relkind check

On 2017/02/13 14:59, Michael Paquier wrote: > On Fri, Feb 10, 2017 at 4:29 PM, Amit Langote wrote: >> On 2017/02/10 14:32, Michael Paquier wrote: >>> The visibility checks are localized in pg_visibility.c and the storage >>> checks in pgstatindex.c, so yes we could have macros in those files. >>>

Re: [HACKERS] pg_waldump's inclusion of backend headers is a mess

On Tue, Feb 14, 2017 at 12:42 PM, Robert Haas wrote: > Therefore, I proposed the attached patch, which splits spgxlog.h out > of spgist_private.h, nbtxlog.h out of nbtree.h, gistxlog.h out of > gist_private.h, and ginxlog.h and ginblock.h out of gin_private.h. > These new

Re: [HACKERS] Parallel bitmap heap scan

On Tue, Feb 14, 2017 at 6:51 AM, Haribabu Kommi wrote: > +#if SIZEOF_DSA_POINTER == 4 > +typedef uint32 dsa_pointer; > +#else > +typedef uint64 dsa_pointer; > +#endif > > I feel the declaration of the above typdef can be moved into the > section above if we going with

Re: [HACKERS] [Bug fix] PQsendQuery occurs error when target_session_attrs is set to read-write

On Thu, Feb 2, 2017 at 3:01 PM, Higuchi, Daisuke wrote: > From: Michael Paquier [mailto:michael.paqu...@gmail.com] >>This has not been added yet to the next CF. As Ashutosh mentioned >>things tend to be easily forgotten. So I have added it here:

Re: [HACKERS] possibility to specify template database for pg_regress

2017-02-14 3:50 GMT+01:00 Andres Freund : > On 2017-02-14 11:46:52 +0900, Michael Paquier wrote: > > > I still fail to see why --use-existing as suggested in > > > https://www.postgresql.org/message-id/20170208002900. > vkldujzfkwbvq...@alap3.anarazel.de > > > isn't

Re: [HACKERS] parallelize queries containing subplans

On Thu, Feb 2, 2017 at 9:23 AM, Amit Kapila wrote: > On Wed, Feb 1, 2017 at 10:04 PM, Robert Haas wrote: >> On Tue, Jan 31, 2017 at 6:01 AM, Amit Kapila wrote: >>> Moved this patch to next CF. >> >> So here is what seems

Re: [HACKERS] Removal of deprecated views pg_user, pg_group, pg_shadow

On Mon, Feb 13, 2017 at 5:38 PM, Stephen Frost wrote: > I really do not think the PG core project should be held hostage by an > external and apparently not-really-maintained project. What if we > introduce some other difference in PG10 that breaks pgAdmin3? Are we > going

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On Tue, Feb 14, 2017 at 11:32 AM, Andreas Karlsson wrote: > On 02/13/2017 06:31 AM, Michael Paquier wrote: >> Er, something like that as well, no? >> DETAIL: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s. > > REINDEX (VERBOSE) currently prints one such line per index,

Re: [HACKERS] Removal of deprecated views pg_user, pg_group, pg_shadow

On Mon, Feb 13, 2017 at 5:29 PM, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> On Thu, Feb 9, 2017 at 8:54 PM, Stephen Frost wrote: >> > Note that these views have not been consistently maintained and have >> > ended up including

Re: [HACKERS] Parallel bitmap heap scan

On Mon, Feb 13, 2017 at 8:48 AM, Dilip Kumar wrote: > On Mon, Feb 13, 2017 at 6:24 PM, Robert Haas wrote: >> I don't think it's acceptable (or necessary) to move the DSA >> definitions into postgres.h. Why do you think you need to do that, >> vs.

Re: [HACKERS] log_autovacuum_min_duration doesn't log VACUUMs

On Mon, Feb 13, 2017 at 5:19 PM, Simon Riggs wrote: > On 13 February 2017 at 17:12, Robert Haas wrote: >> On Sun, Feb 12, 2017 at 9:20 PM, Jim Nasby wrote: >>> On 2/10/17 2:33 PM, Robert Haas wrote: That having been

[HACKERS] pg_waldump's inclusion of backend headers is a mess

Dilip complained on another thread about the apparent difficulty of getting the system to compile after adding a reference to dsa_pointer to tidbitmap.c: https://www.postgresql.org/message-id/CAFiTN-u%3DBH_b0QE9FG%2B%2B_Ht6Q%3DF84am%3DJ-rt7fNbQkq3%2BqX3VQ%40mail.gmail.com I dug into the problem

Re: [HACKERS] Provide list of subscriptions and publications in psql's completion

On Tue, Feb 14, 2017 at 2:07 AM, Fujii Masao wrote: > No, the tab-completions for ALTER/DROP PUBLICATION should show the local > publications because those commands drop and alter the local ones. OTOH, > CREATE/ALTER SUBSCRIPTOIN ... PUBLICATION should show nothing because

Re: [HACKERS] Possible TODO: allow arbitrary expressions in event trigger WHEN

Jim Nasby writes: > Is there a reason not to allow $SUBJECT? Specifically, it'd be nice to > be able to do something like WHEN tag LIKE 'ALTER%'. Seems like it would be a seriously bad idea for such an expression to be able to invoke arbitrary SQL code. What if it

Re: [HACKERS] possibility to specify template database for pg_regress

On 2017-02-14 11:46:52 +0900, Michael Paquier wrote: > > I still fail to see why --use-existing as suggested in > > https://www.postgresql.org/message-id/20170208002900.vkldujzfkwbvq...@alap3.anarazel.de > > isn't sufficient. > > Some tests create objects without removing them, meaning that >

Re: [HACKERS] possibility to specify template database for pg_regress

On Tue, Feb 14, 2017 at 11:36 AM, Andres Freund wrote: > On 2017-02-13 20:59:43 +0100, Pavel Stehule wrote: >> Hi >> >> 2017-02-13 6:46 GMT+01:00 Michael Paquier : >> >> > On Sat, Feb 11, 2017 at 3:03 PM, Pavel Stehule >> >

Re: [HACKERS] possibility to specify template database for pg_regress

On 2017-02-13 20:59:43 +0100, Pavel Stehule wrote: > Hi > > 2017-02-13 6:46 GMT+01:00 Michael Paquier : > > > On Sat, Feb 11, 2017 at 3:03 PM, Pavel Stehule > > wrote: > > > here is new update - check is done before any creating > > > > It may

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On 02/13/2017 06:31 AM, Michael Paquier wrote: - What should we do with REINDEX DATABASE CONCURRENTLY and the system catalog? I so not think we can reindex the system catalog concurrently safely, so what should REINDEX DATABASE do with the catalog indexes? Skip them, reindex them while taking

Re: [HACKERS] Logical Replication and Character encoding

At Sat, 4 Feb 2017 21:27:32 +0100, Petr Jelinek wrote in > Hmm I wonder if we should just make the subscriber send the > client_encoding always (based on server encoding of the subscriber). > That should solve

Re: [HACKERS] PATCH: two slab-like memory allocators

Hi, On 2017-02-11 14:40:18 +0100, Tomas Vondra wrote: > On 02/11/2017 02:33 AM, Andres Freund wrote: > > > I have a hard time believing this the cache efficiency of linked lists > > > (which may or may not be real in this case) out-weights this, but if you > > > want to try, be my guest. > > > >

Re: [HACKERS] renaming pg_resetxlog to pg_resetwal has broken pg_upgrade.

On Tue, Feb 14, 2017 at 9:09 AM, Jeff Janes wrote: > check for "/usr/local/pgsql9_6/bin/pg_resetwal" failed: No such file or > directory > > This looks somewhat complicated to fix. Should check_bin_dir test the old > cluster version, and make a deterministic check based on

Re: [HACKERS] Parallel Index Scans

On Mon, Feb 13, 2017 at 5:47 PM, Robert Haas wrote: > On Sat, Feb 11, 2017 at 6:35 PM, Amit Kapila wrote: > Why can't we rely on _bt_walk_left? The reason is mentioned in comments, but let me try to explain with some example. When

Re: [HACKERS] [WIP]Vertical Clustered Index (columnar store extension)

On Tue, Feb 14, 2017 at 2:57 AM, Konstantin Knizhnik < k.knizh...@postgrespro.ru> wrote: > Hi, > > I wonder if it is possible to somehow benchmark your clustered index > implementation. > I tried to create VCI index for lineitem table from TPC and run Q6 query. > After index creation Postgres is

Re: [HACKERS] Parallel bitmap heap scan

On Tue, Feb 14, 2017 at 12:48 AM, Dilip Kumar wrote: > On Mon, Feb 13, 2017 at 6:24 PM, Robert Haas > wrote: > > I don't think it's acceptable (or necessary) to move the DSA > > definitions into postgres.h. Why do you think you need to do that, > >

[HACKERS] Set of fixes for WAL consistency check facility

Hi all, Beginning a new thread to raise awareness... As already reported here, I had a look at what has been committed in a507b869: https://www.postgresql.org/message-id/CAB7nPqRzCQb=vdfhvmtp0hmlbhu6z1agdo4gjsup-hp8jx+...@mail.gmail.com Here are a couple of things I have noticed while looking at

[HACKERS] renaming pg_resetxlog to pg_resetwal has broken pg_upgrade.

Upgrading from 9.6 to dev, I now get: $ rm bisectdata -r ; bisect/bin/pg_ctl initdb -D bisectdata; bisect/bin/pg_upgrade -b /usr/local/pgsql9_6/bin/ -B bisect/bin/ -d 96 -D bisectdata/ check for "/usr/local/pgsql9_6/bin/pg_resetwal" failed: No such file or directory This looks somewhat

Re: [HACKERS] libpq Alternate Row Processor

On Mon, Feb 13, 2017 Merlin Moncure wrote: >A barebones callback mode ISTM is a complete departure from the classic >PGresult interface. This code is pretty unpleasant IMO: acct->abalance = *((int*)PQgetvalue(res, 0, i)); abalance = acct->__bswap_32(acct->abalance); > Your code is faster but

[HACKERS] Possible TODO: allow arbitrary expressions in event trigger WHEN

Is there a reason not to allow $SUBJECT? Specifically, it'd be nice to be able to do something like WHEN tag LIKE 'ALTER%'. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble!

Re: [HACKERS] Removal of deprecated views pg_user, pg_group, pg_shadow

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Mon, Feb 13, 2017 at 2:42 PM, Alvaro Herrera > wrote: > > Well, we can remove them from PG10 and pgAdmin3 (and others) be adjusted > > to use the new ones, conditionally on server version. Surely pgAdmin3 > > is

Re: [HACKERS] Removal of deprecated views pg_user, pg_group, pg_shadow

* Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Feb 9, 2017 at 8:54 PM, Stephen Frost wrote: > > Note that these views have not been consistently maintained and have > > ended up including some role attributes from recent versions > > That's not a bug. According to

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

On Thu, Feb 9, 2017 at 2:03 AM, Ashutosh Bapat wrote: >> >> 0004-hj-refactor-batch-increases-v4.patch: >> >> Modify the existing hash join code to detect work_mem exhaustion at >> the point where chunks are allocated, instead of checking after every >> tuple

Re: [HACKERS] log_autovacuum_min_duration doesn't log VACUUMs

On 13 February 2017 at 17:12, Robert Haas wrote: > On Sun, Feb 12, 2017 at 9:20 PM, Jim Nasby wrote: >> On 2/10/17 2:33 PM, Robert Haas wrote: >>> That having been said, I think it could certainly be useful to have >>> more control over what DDL

Re: [HACKERS] Small improvement to parallel query docs

On 14 February 2017 at 10:56, Brad DeJong wrote: > David Rowley wrote: >> I propose we just remove the whole paragraph, and mention about >> the planning and estimated number of groups stuff in another new paragraph. >> >> I've attached a patch to this effect ... > > s/In a

Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove all references to "xlog" from SQL-callable functions in p

On Tue, Feb 14, 2017 at 2:31 AM, Fujii Masao wrote: > On Tue, Feb 14, 2017 at 2:06 AM, Robert Haas wrote: >> On Mon, Feb 13, 2017 at 11:43 AM, Fujii Masao wrote: >>> On Fri, Feb 10, 2017 at 5:36 AM, Robert Haas

Re: [HACKERS] Small improvement to parallel query docs

David Rowley wrote: > I propose we just remove the whole paragraph, and mention about > the planning and estimated number of groups stuff in another new paragraph. > > I've attached a patch to this effect ... s/In a worse case scenario/In the worst case scenario,/ Other than that, the phrasing

Re: [HACKERS] Small improvement to parallel query docs

On 14 February 2017 at 10:10, Brad DeJong wrote: > Robert Haas wrote: > >> +COUNT(*), each worker must compute subtotals which later >> must >> +be combined to produce an overall total in order to produce the final >> +answer. If the query involves a GROUP BY

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

On 14 Feb. 2017 06:15, "Robert Haas" wrote: On Mon, Jan 23, 2017 at 9:12 PM, Robert Haas wrote: > According to the documentation for COPY IN mode, "If the COPY command > was issued via an extended-query message, the backend will now discard >

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Mon, Feb 13, 2017 at 3:40 PM, Fabien COELHO wrote: > > Hello Robert, > > [...] I think we should try to make this REALLY simple. We don't really >> want to have everybody have to change their PROMPT1 and PROMPT2 strings for >> this one feature. >> > > Ok. I think that we

Re: [HACKERS] Small improvement to parallel query docs

Robert Haas wrote: > +COUNT(*), each worker must compute subtotals which later must > +be combined to produce an overall total in order to produce the final > +answer. If the query involves a GROUP BY clause, > +separate subtotals must be computed for each group seen by each

Re: [HACKERS] libpq Alternate Row Processor

On Mon, Feb 13, 2017 at 8:46 AM, Kyle Gearhart wrote: > On 2/9/17 7:15 PM, Jim Nasby wrote: >> Can you run a trace to see where all the time is going in the single row >> case? I don't see an obvious time-suck with a quick look through the code. >> It'd be

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

Hello Corey, I went back to master and re-applied v11, something must have gotten lost in translation. Probably you need "git add" for added files? About v14: patch applies, make check ok, psql tap tests ok. All seems fine to me. Test coverage is better than a lot of other features. Code

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Mon, Feb 13, 2017 at 11:29 AM, Robert Haas wrote: > possible states here. Just when you've figured out what tfzffft I agree with what you've said, but wanted to point out that any condition that follows a 'z' would itself be 'z'. Not that tfz is much better.

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

Hello Robert, [...] I think we should try to make this REALLY simple. We don't really want to have everybody have to change their PROMPT1 and PROMPT2 strings for this one feature. Ok. I think that we agree that the stack was too much details. How about just introducing a new value for

Re: [HACKERS] Small improvement to parallel query docs

On Mon, Feb 13, 2017 at 3:29 PM, David Rowley wrote: > On 14 February 2017 at 09:21, Robert Haas wrote: >> On Sun, Feb 12, 2017 at 7:16 PM, David Rowley >> -table. Each worker will execute the outer side of the plan in full, >> which >> -

Re: [HACKERS] Small improvement to parallel query docs

On 14 February 2017 at 09:21, Robert Haas wrote: > On Sun, Feb 12, 2017 at 7:16 PM, David Rowley > -table. Each worker will execute the outer side of the plan in full, which > -is why merge joins are not supported here. The outer side of a merge join > -will

Re: [HACKERS] Small improvement to parallel query docs

On Sun, Feb 12, 2017 at 7:16 PM, David Rowley wrote: > Tomas Vondra pointed out to me that there's an error in parallel.sgml > which confuses the inner and outer sides of the join. > > I've attached a patch which fixes this, although I think I'm still > missing the

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Mon, Feb 13, 2017 at 3:04 PM, Fabien COELHO wrote: > > Hello Corey, > > That effort was creating as many headaches as it solved. Rolled back v12 >> except for doc paragraph, added more descriptive tap test names. Enjoy. >> > > The TAP tests are missing from the patch, not

Re: [HACKERS] Removal of deprecated views pg_user, pg_group, pg_shadow

On Mon, Feb 13, 2017 at 2:42 PM, Alvaro Herrera wrote: > Robert Haas wrote: >> My big objection to removing these views is that it will break pgAdmin >> 3, which uses all three of these views. I understand that the pgAdmin >> community is now moving away from pgAdmin 3

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

Hello Corey, That effort was creating as many headaches as it solved. Rolled back v12 except for doc paragraph, added more descriptive tap test names. Enjoy. The TAP tests are missing from the patch, not sure why... The stack cleanup is nicer with pop calls. Two debatable suggestions about

Re: [HACKERS] possibility to specify template database for pg_regress

Hi 2017-02-13 6:46 GMT+01:00 Michael Paquier : > On Sat, Feb 11, 2017 at 3:03 PM, Pavel Stehule > wrote: > > here is new update - check is done before any creating > > It may be better to do any checks before dropping existing databases > as

Re: [HACKERS] Removal of deprecated views pg_user, pg_group, pg_shadow

Robert Haas wrote: > My big objection to removing these views is that it will break pgAdmin > 3, which uses all three of these views. I understand that the pgAdmin > community is now moving away from pgAdmin 3 and toward pgAdmin 4, but > I bet that pgAdmin 3 still has significant usage and will

Re: [HACKERS] Removal of deprecated views pg_user, pg_group, pg_shadow

On 02/13/2017 11:00 AM, Robert Haas wrote: > My big objection to removing these views is that it will break pgAdmin > 3, which uses all three of these views. I understand that the pgAdmin > community is now moving away from pgAdmin 3 and toward pgAdmin 4, but > I bet that pgAdmin 3 still has

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

> > I wasn't too happy with the extra param, either. Having moved the guts to >> conditional.c, I'm happy with that change and can move the stack head back >> to scan_state with a clear conscience. >> > > That effort was creating as many headaches as it solved. Rolled back v12 except for doc

Re: [HACKERS] LWLock optimization for multicore Power machines

On 02/13/2017 03:16 PM, Bernd Helmle wrote: Am Samstag, den 11.02.2017, 15:42 +0300 schrieb Alexander Korotkov: Thus, I see reasons why in your tests absolute results are lower than in my previous tests. 1. You use 28 physical cores while I was using 32 physical cores. 2. You run tests in

Re: [HACKERS] Removal of deprecated views pg_user, pg_group, pg_shadow

On Thu, Feb 9, 2017 at 8:54 PM, Stephen Frost wrote: > Note that these views have not been consistently maintained and have > ended up including some role attributes from recent versions That's not a bug. According to the documentation, these views exist for compatibility

Re: [HACKERS] WIP: About CMake v2

On Mon, Feb 13, 2017 at 10:52 AM, Peter Eisentraut wrote: > People have all kinds of expectations on how the build system behaves. > It's not just ./configure; make; make install. All kinds of niche and > edge cases have evolved over the years. Variables you

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Mon, Feb 13, 2017 at 11:26 AM, Corey Huinker wrote: > ISTM that it is kind of a regression, because logically this is about the >> scan state so it should be in the corresponding structure, and having two >> structures to pass the scan state is not an improvement... >

[HACKERS] Re: [COMMITTERS] pgsql: Remove all references to "xlog" from SQL-callable functions in p

On Tue, Feb 14, 2017 at 2:06 AM, Robert Haas wrote: > On Mon, Feb 13, 2017 at 11:43 AM, Fujii Masao wrote: >> On Fri, Feb 10, 2017 at 5:36 AM, Robert Haas wrote: >>> Remove all references to "xlog" from SQL-callable functions

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

On Mon, Jan 23, 2017 at 9:12 PM, Robert Haas wrote: > According to the documentation for COPY IN mode, "If the COPY command > was issued via an extended-query message, the backend will now discard > frontend messages until a Sync message is received, then it will issue >

[HACKERS] Re: [COMMITTERS] pgsql: Remove all references to "xlog" from SQL-callable functions in p

On Mon, Feb 13, 2017 at 11:43 AM, Fujii Masao wrote: > On Fri, Feb 10, 2017 at 5:36 AM, Robert Haas wrote: >> Remove all references to "xlog" from SQL-callable functions in pg_proc. >> >> Commit f82ec32ac30ae7e3ec7c84067192535b2ff8ec0e renamed the

Re: [HACKERS] log_autovacuum_min_duration doesn't log VACUUMs

On Sun, Feb 12, 2017 at 9:20 PM, Jim Nasby wrote: > On 2/10/17 2:33 PM, Robert Haas wrote: >> That having been said, I think it could certainly be useful to have >> more control over what DDL gets logged in foreground processes. > > FWIW, this is a significant problem

Re: [HACKERS] Provide list of subscriptions and publications in psql's completion

On Fri, Feb 10, 2017 at 1:52 PM, Michael Paquier wrote: > On Tue, Feb 7, 2017 at 6:35 AM, Peter Eisentraut > wrote: >> On 2/6/17 10:54 AM, Fujii Masao wrote: >>> Yes, that's an option. And, if we add dbid to pg_stat_subscription, >>>

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On Fri, Feb 10, 2017 at 8:39 PM, Peter Geoghegan wrote: > On Thu, Feb 9, 2017 at 2:32 PM, Andres Freund wrote: >> Except that the proposed names aren't remotely like that... ;). > > Revision attached -- V5. We now REVOKE ALL on both functions, as > Robert

Re: [HACKERS] Should we cacheline align PGXACT?

Hi All, I too have performed benchmarking of this patch on a large machine (with 128 CPU(s), 520GB RAM, intel x86-64 architecture) and would like to share my observations for the same (Please note that, as I had to reverify readings on few client counts, it did take some time for me to share

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On Thu, Feb 9, 2017 at 5:32 PM, Andres Freund wrote: >> > Again, some parts of the code doing something bad isn't a good argument >> > for doing again. Releasing locks early is a bad pattern, because backend >> > code isn't generally safe against it, we have special code-paths

Re: [HACKERS] Sum aggregate calculation for single precsion real

On 13.02.2017 19:20, Tom Lane wrote: Konstantin Knizhnik writes: I wonder why SUM aggregate is calculated for real (float4) type using floating point accumulator? If you can't deal with the vagaries of floating-point arithmetic, you shouldn't be storing your data

[HACKERS] Re: [COMMITTERS] pgsql: Remove all references to "xlog" from SQL-callable functions in p

On Fri, Feb 10, 2017 at 5:36 AM, Robert Haas wrote: > Remove all references to "xlog" from SQL-callable functions in pg_proc. > > Commit f82ec32ac30ae7e3ec7c84067192535b2ff8ec0e renamed the pg_xlog > directory to pg_wal. To make things consistent, and because "xlog" is >

Re: [HACKERS] IF NOT EXISTS option for CREATE SERVER and CREATE USER MAPPING statements

On 01/13/2017 08:36 AM, Anastasia Lubennikova wrote: > I implemented IF NOT EXISTS option for CREATE SERVER and CREATE USER > MAPPING statements > for one of our customers. > I think other users can also find it useful for scripting and > automated tasks. > The patches themselves are small and

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On Thu, Feb 9, 2017 at 8:15 PM, Peter Geoghegan wrote: > BTW, aren't there cases where a PARALLEL SAFE function that needs to > acquire locks on some arbitrary relation not referenced in the query > can get locks on its own, which may only last as long as the parallel > worker's

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Sat, Feb 11, 2017 at 2:43 AM, Fabien COELHO wrote: >> Ok, so that's not just PROMPT_READY, that's every prompt...which might be >> ok. ? is a great optional cue, and you're thinking on 2 levels deep, 2nd >> level always being '.'? > > Yep. The idea is to keep it short, but

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

> > ISTM that it is kind of a regression, because logically this is about the > scan state so it should be in the corresponding structure, and having two > structures to pass the scan state is not an improvement... I wasn't too happy with the extra param, either. Having moved the guts to

Re: [HACKERS] Sum aggregate calculation for single precsion real

Konstantin Knizhnik writes: > I wonder why SUM aggregate is calculated for real (float4) type using > floating point accumulator? If you can't deal with the vagaries of floating-point arithmetic, you shouldn't be storing your data in float format. Use numeric. > Are

Re: [HACKERS] Should we cacheline align PGXACT?

Am Montag, den 13.02.2017, 16:55 +0300 schrieb Alexander Korotkov: > > Thank you for testing. > > Yes, influence seems to be low.  But nevertheless it's important to > insure > that there is no regression here. > Despite pg_prewarm'ing and running tests 300s, there is still > significant >

Re: [HACKERS] DROP SUBSCRIPTION and ROLLBACK

On Mon, Feb 13, 2017 at 4:05 PM, Masahiko Sawada wrote: > On Sat, Feb 11, 2017 at 8:18 PM, Petr Jelinek > wrote: >> On 10/02/17 19:55, Masahiko Sawada wrote: >>> On Thu, Feb 9, 2017 at 12:44 AM, Petr Jelinek >>>

Re: [HACKERS] [WIP]Vertical Clustered Index (columnar store extension)

Hi, I wonder if it is possible to somehow benchmark your clustered index implementation. I tried to create VCI index for lineitem table from TPC and run Q6 query. After index creation Postgres is not using parallel execution plan any more but speed of sequential plan is not changed and

Re: [HACKERS] removing tsearch2

On Fri, Feb 10, 2017 at 1:41 PM, Robert Haas wrote: > Anyway, it seems like the consensus here is unanimous. Unless there > are a LARGE number of contrary votes in the meanwhile, I'll go make > this happen sometime next week. Done. -- Robert Haas EnterpriseDB:

Re: [HACKERS] Should we cacheline align PGXACT?

Alexander Korotkov wrote: > Yes, influence seems to be low. But nevertheless it's important to insure > that there is no regression here. > Despite pg_prewarm'ing and running tests 300s, there is still significant > variation. > For instance, with clients count = 80: > * pgxact-result-2.txt –

Re: [HACKERS] WIP: About CMake v2

On 2/8/17 4:44 PM, Andres Freund wrote: >> Well, I find it a bit scary. If you do the big switch all at once, then >> you will have to dedicate the following 3 months to fixing complaints >> from developers and build farmers. > > That'll be the case just as well if we spread it out over two

Re: [HACKERS] [ patch ] pg_dump: new --custom-fetch-table and --custom-fetch-value parameters

On Sat, Feb 11, 2017 at 9:56 AM, Andrea Urbani wrote: > I'm a beginner here... anyway I try to share my ideas. > > My situation is changed in a worst state: I'm no more able to make a pg_dump > neither with my custom fetch value (I have tried "1" as value = one row at > the

Re: [HACKERS] libpq Alternate Row Processor

On 2/9/17 7:15 PM, Jim Nasby wrote: > Can you run a trace to see where all the time is going in the single row > case? I don't see an obvious time-suck with a quick look through the code. > It'd be interesting to see how things change if you eliminate the filler > column from the SELECT.

Re: [HACKERS] LWLock optimization for multicore Power machines

Am Samstag, den 11.02.2017, 15:42 +0300 schrieb Alexander Korotkov: > Thus, I see reasons why in your tests absolute results are lower than > in my > previous tests. > 1.  You use 28 physical cores while I was using 32 physical cores. > 2.  You run tests in PowerVM while I was running test on bare

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

Hello hackers, There were many discussions concerning possible ways of speeding-up Postgres. Different approaches were suggested: - JIT (now we have three different prototype implementations based on LLVM) - Chunked (vectorized) executor - Replacing pull with push - Columnar store

Re: [HACKERS] Should we cacheline align PGXACT?

On Mon, Feb 13, 2017 at 3:34 PM, Bernd Helmle wrote: > Am Samstag, den 11.02.2017, 00:28 +0100 schrieb Tomas Vondra: > > Comparing averages of tps, measured on 5 runs (each 5 minutes long), > > the > > difference between master and patched master is usually within 2%, > >

Re: [HACKERS] Logical replication existing data copy

On 2017-02-11 11:16, Erik Rijkers wrote: On 2017-02-08 23:25, Petr Jelinek wrote: 0001-Use-asynchronous-connect-API-in-libpqwalreceiver-v2.patch 0002-Always-initialize-stringinfo-buffers-in-walsender-v2.patch 0003-Fix-after-trigger-execution-in-logical-replication-v2.patch

Re: [HACKERS] Parallel bitmap heap scan

On Mon, Feb 13, 2017 at 6:24 PM, Robert Haas wrote: > I don't think it's acceptable (or necessary) to move the DSA > definitions into postgres.h. Why do you think you need to do that, > vs. just including dsa.h in a few more places? I need to access dsa_pointer in

Re: [HACKERS] Parallel Append implementation

On Mon, Feb 6, 2017 at 11:06 AM, Amit Khandekar wrote: > Ashutosh Bapat wrote: >>> We may want to think about a third goal: preventing too many workers >>> from executing the same plan. As per comment in get_parallel_divisor() >>> we do

Re: [HACKERS] 'text' instead of 'unknown' in Postgres 10

On Mon, Feb 13, 2017 at 3:09 AM, Jim Nasby wrote: > On 2/7/17 9:16 AM, Daniele Varrazzo wrote: >> >> Thank you for the clarification: I will assume the behaviour cannot be >> maintained on PG 10 and think whether the treatment of '{}' is too >> magical and drop it

Re: [HACKERS] Parallel bitmap heap scan

On Sat, Feb 11, 2017 at 1:41 AM, Dilip Kumar wrote: > I tried my best, please check the latest patch (0001). I don't think it's acceptable (or necessary) to move the DSA definitions into postgres.h. Why do you think you need to do that, vs. just including dsa.h in a few

Re: [HACKERS] Should we cacheline align PGXACT?

Am Samstag, den 11.02.2017, 00:28 +0100 schrieb Tomas Vondra: > Comparing averages of tps, measured on 5 runs (each 5 minutes long), > the  > difference between master and patched master is usually within 2%, > which  > is pretty much within noise. > > I'm attaching spreadsheets with summary of

Re: [HACKERS] Parallel Index Scans

On Sat, Feb 11, 2017 at 6:35 PM, Amit Kapila wrote: Why can't we rely on _bt_walk_left? >>> The reason is mentioned in comments, but let me try to explain with >>> some example. When you reach that point of code, it means that either >>> the current page (assume

[HACKERS] UPDATE of partition key

Currently, an update of a partition key of a partition is not allowed, since it requires to move the row(s) into the applicable partition. Attached is a WIP patch (update-partition-key.patch) that removes this restriction. When an UPDATE causes the row of a partition to violate its partition

  1   2   >