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

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 to still have something to say "there are more levels" in the stack, hence the one

Re: [HACKERS] Parallel bitmap heap scan

On Wed, Feb 8, 2017 at 8:07 AM, Robert Haas wrote: Thanks for the detailed review and your valuable feedback. > I think it would be useful to break the remaining patch into two > parts, one that enhances the tidbitmap.c API and another that uses > that to implement

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

Hi 2017-02-10 6:00 GMT+01:00 Michael Paquier : > On Thu, Feb 9, 2017 at 5:13 AM, Pavel Stehule > wrote: > > here is a patch > > Thanks. > > - for (sl = dblist; sl; sl = sl->next) > - create_database(sl->str); > + if

Re: [HACKERS] Parallel Index Scans

On Fri, Feb 10, 2017 at 11:27 PM, Robert Haas wrote: > On Wed, Feb 1, 2017 at 8:20 AM, Amit Kapila wrote: >>> The hunk in indexam.c looks like a leftover that can be omitted. >> >> It is not a leftover hunk. Earlier, the patch has the same check >>

Re: [HACKERS] Passing query string to workers

> > > > There are some spacing issues in the code. For example, > > + estate->es_queryString = (char > > *)palloc0(strlen(queryDesc->sourceText) + 1); > > + /*Estimate space for query text. */ > > pgindent might be helpful to track all such changes. > > > Fixed. > > +#define

Re: [HACKERS] Should we cacheline align PGXACT?

On 02/11/2017 02:44 AM, Ashutosh Sharma wrote: Hi, I am currently testing this patch on a large machine and will share the test results in few days of time. FWIW it might be interesting to have comparable results from the same benchmarks I did. The scripts available in the git repositories

Re: [HACKERS] Should we cacheline align PGXACT?

Hi, I am currently testing this patch on a large machine and will share the test results in few days of time. Please excuse any grammatical errors as I am using my mobile device. Thanks. On Feb 11, 2017 04:59, "Tomas Vondra" wrote: > Hi, > > As discussed at the

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

On 2017-02-11 02:13:59 +0100, Tomas Vondra wrote: > > > + /* move the whole block to the right place in the freelist */ > > > + dlist_delete(>node); > > > + dlist_push_head(>freelist[block->nfree], >node); > > > > Hm. What if we, instead of the array of doubly linked lists, just kept > > a

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

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 suggested, instead of the previous approach of having a hard-coded superuser check

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

On 2017-02-11 02:13:59 +0100, Tomas Vondra wrote: > On 02/09/2017 10:37 PM, Andres Freund wrote: > > Hi, > > > > On 2016-12-13 01:45:13 +0100, Tomas Vondra wrote: > > > src/backend/utils/mmgr/Makefile | 2 +- > > > src/backend/utils/mmgr/aset.c | 115 + > >

Re: [HACKERS] multivariate statistics (v19)

On 02/08/2017 07:40 PM, Dean Rasheed wrote: On 8 February 2017 at 16:09, David Fetter wrote: Combinations are n!/(k! * (n-k)!), so computing those is more along the lines of: unsigned long long choose(unsigned long long n, unsigned long long k) { if (k > n) {

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

On 02/09/2017 10:37 PM, Andres Freund wrote: Hi, On 2016-12-13 01:45:13 +0100, Tomas Vondra wrote: src/backend/utils/mmgr/Makefile | 2 +- src/backend/utils/mmgr/aset.c | 115 + src/backend/utils/mmgr/memdebug.c | 131

Re: [HACKERS] Checksums by default?

Hi, I've repeated those benchmarks on a much smaller/older machine, with only minimal changes (mostly related to RAM and cores available). I've expected to see more significant differences, assuming that newer CPUs will handle the checksumming better, but to my surprise the impact of

Re: [HACKERS] Should we cacheline align PGXACT?

Hi, As discussed at the Developer meeting ~ a week ago, I've ran a number of benchmarks on the commit, on a small/medium-size x86 machines. I currently don't have access to a machine as big as used by Alexander (with 72 physical cores), but it seems useful to verify the patch does not have

Re: [HACKERS] WIP: About CMake v2

On 2017-02-10 10:22:34 -0800, Andres Freund wrote: > On 2017-02-10 12:07:15 -0500, Robert Haas wrote: > > But also, I'm not really sure whether this conversion makes sense. I > > mean, any build system is going to require some work, and accordingly > > our present build systems require some work.

Re: [HACKERS] WIP: About CMake v2

On 11 Feb. 2017 08:42, "Andrew Dunstan" wrote: On 02/10/2017 01:27 PM, Magnus Hagander wrote: > On Fri, Feb 10, 2017 at 6:07 PM, Robert Haas > wrote: > > On Mon, Jan 30, 2017 at 10:26 AM, Peter

Re: [HACKERS] Reporting xmin from VACUUMs

Robert Haas wrote: > On Fri, Feb 10, 2017 at 3:30 AM, Simon Riggs wrote: > > We've added xmin info to pg_stat_activity and pg_stat_replication, but > > VACUUM doesn't yet report which xmin value it used when it ran. > > > > Small patch to add this info to VACUUM output. >

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

> > calvin=> \if true > calvin?t=> SELECT 1 + > calvin?t-> 2; > 3 > calvin?t=> \if true > calvin?t=> \echo hello > hello > calvin?t=> \endif > calvin?t=> \else > calvin?z=> \echo ignored > calvin?t=> \endif > calvin=> > Ok, so that's not just PROMPT_READY, that's

Re: [HACKERS] Reporting xmin from VACUUMs

On Fri, Feb 10, 2017 at 3:30 AM, Simon Riggs wrote: > We've added xmin info to pg_stat_activity and pg_stat_replication, but > VACUUM doesn't yet report which xmin value it used when it ran. > > Small patch to add this info to VACUUM output. It seems sensible to me to do

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

Hello, I'm looking forward to the doc update. My 0.02€ about prompting: Given that there is no more barking, then having some prompt indication that the code is inside a conditional branch becomes more important, so ISTM that there should be some plan to add it. Yeah, prompting just got

Re: [HACKERS] Add doc advice about systemd RemoveIPC

On 12/31/16 11:43 AM, Tom Lane wrote: > Magnus Hagander writes: >> I still think that some wording in the direction of the fact that the >> majority of all users won't actually have this problem is the right thing >> to do (regardless of our previous history in the area as

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

On 1/28/17 1:33 PM, Fabrízio de Royes Mello wrote: > I did what you suggested making CURRENT_DATABASE reserved but I got the > following error during the bootstrap: current_database is also used as a function name, so you need to do some parser work to get it working in all the right ways. Hard

Re: [HACKERS] sequence data type

On 2/1/17 10:01 PM, Michael Paquier wrote: > On Wed, Feb 1, 2017 at 10:02 AM, Michael Paquier > wrote: >> On Wed, Feb 1, 2017 at 1:11 AM, Peter Eisentraut >> wrote: >>> And here is a rebased patch for the original feature. I think

Re: [HACKERS] log_autovacuum_min_duration doesn't log VACUUMs

On Fri, Feb 10, 2017 at 3:38 AM, Simon Riggs wrote: > I guess its fairly obvious in the title, but > log_autovacuum_min_duration doesn't log VACUUMs only autovacuums. > > What isn't obvious is why that restruction is useful. > > I say that it would be helpful to log all

Re: [HACKERS] removing tsearch2

On 02/10/2017 01:27 PM, Josh Berkus wrote: > On 02/10/2017 10:18 AM, Peter Geoghegan wrote: >> On Fri, Feb 10, 2017 at 3:28 AM, Robert Haas wrote: > Works for me. +1 >>> OK, that's three votes in favor of removing tsearch2 (from core, >>> anyone who wants it can

Re: [HACKERS] Proposal : For Auto-Prewarm.

On Thu, Feb 9, 2017 at 1:47 AM, Beena Emerson wrote: >> Won't it be simple if you consider -1 as a value to just load library? >> For *_interval = -1, it will neither load nor dump. >> > +1 > That is what I thought was the behaviour we decided upon for -1. Right. I

Re: [HACKERS] Proposal : For Auto-Prewarm.

On Tue, Feb 7, 2017 at 2:04 AM, Amit Kapila wrote: > On Tue, Feb 7, 2017 at 10:44 AM, Mithun Cy wrote: >> >> == >> One problem now I have kept it open is multiple "auto pg_prewarm dump" >> can be launched even if already a

Re: [HACKERS] WIP: About CMake v2

On 02/10/2017 01:27 PM, Magnus Hagander wrote: > On Fri, Feb 10, 2017 at 6:07 PM, Robert Haas > wrote: > > On Mon, Jan 30, 2017 at 10:26 AM, Peter Eisentraut >

Re: [HACKERS] DROP SUBSCRIPTION and ROLLBACK

On Thu, Feb 9, 2017 at 12:44 AM, Petr Jelinek wrote: > On 08/02/17 07:40, Masahiko Sawada wrote: >> On Wed, Feb 8, 2017 at 9:01 AM, Michael Paquier >> wrote: >>> On Wed, Feb 8, 2017 at 1:30 AM, Fujii Masao wrote:

Re: [HACKERS] WIP: About CMake v2

On Feb 10, 2017 19:41, "Andres Freund" wrote: On 2017-02-10 19:33:18 +0100, Magnus Hagander wrote: > I guess we wouldn't, but we'd still need the "replacement for autoconf" > part. So then we're back to maintaining multiple buildsystems. Hm? Do we really need that? Most of

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

> > Shouldn't there be some documentation changes to reflect the behavior on > errors? A precise paragraph about that would be welcome, IMHO. > Oddly enough, the documentation I wrote hadn't addressed invalid booleans, only the error messages did that. The new behavior certainly warrants a

Re: [HACKERS] WIP: About CMake v2

On 2017-02-10 19:33:18 +0100, Magnus Hagander wrote: > I guess we wouldn't, but we'd still need the "replacement for autoconf" > part. So then we're back to maintaining multiple buildsystems. Hm? Do we really need that? Most of the things in an extension you do *not* want to determine separately

Re: [HACKERS] removing tsearch2

On Fri, Feb 10, 2017 at 12:32 PM, Tom Lane wrote: > Robert Haas writes: >> That's not a bad idea, but I think it's an independent issue. If the >> hacks are still needed for an external module, we shouldn't go out of >> our way to remove them even if

Re: [HACKERS] WIP: About CMake v2

On 2017-02-10 20:31:12 +0200, Heikki Linnakangas wrote: > On 02/10/2017 08:27 PM, Magnus Hagander wrote: > > For me a killer feature would be if/when we can get to a point where we can > > have something pgxs-style on cmake that also works on windows. > > > > Our homemade Windows build system

Re: [HACKERS] WIP: About CMake v2

On Fri, Feb 10, 2017 at 7:31 PM, Heikki Linnakangas wrote: > On 02/10/2017 08:27 PM, Magnus Hagander wrote: > >> For me a killer feature would be if/when we can get to a point where we >> can >> have something pgxs-style on cmake that also works on windows. >> >> Our homemade

Re: [HACKERS] WIP: About CMake v2

On 2017-02-10 19:27:55 +0100, Magnus Hagander wrote: > For me a killer feature would be if/when we can get to a point where we can > have something pgxs-style on cmake that also works on windows. That should be quite possible. The ugliest part will be to determine where to include a cmake file

Re: [HACKERS] WIP: About CMake v2

On 02/10/2017 08:27 PM, Magnus Hagander wrote: For me a killer feature would be if/when we can get to a point where we can have something pgxs-style on cmake that also works on windows. Our homemade Windows build system works OK for postgres, and while ugly it is as you say well tested by now.

Re: [HACKERS] WIP: About CMake v2

On Fri, Feb 10, 2017 at 6:07 PM, Robert Haas wrote: > On Mon, Jan 30, 2017 at 10:26 AM, Peter Eisentraut > wrote: > > On 1/30/17 1:28 AM, Andres Freund wrote: > >> Given that fact, I just don't buy why it's a good idea to not also > >>

Re: [HACKERS] removing tsearch2

On 02/10/2017 10:18 AM, Peter Geoghegan wrote: > On Fri, Feb 10, 2017 at 3:28 AM, Robert Haas wrote: Works for me. >>> >>> +1 >> >> OK, that's three votes in favor of removing tsearch2 (from core, >> anyone who wants it can maintain a copy elsewhere). > > +1. > > I'd

Re: [HACKERS] removing tsearch2

On Fri, Feb 10, 2017 at 1:18 PM, Peter Geoghegan wrote: > I'd also be in favor of either removing contrib/isn, or changing it so > that the ISBN country code prefix enforcement went away. That would > actually not imply and real loss of functionality from a practical > perspective,

Re: [HACKERS] Parallel Index Scans

On Thu, Feb 9, 2017 at 1:33 AM, Amit Kapila wrote: > compute_index_pages_v2.patch - This function extracts the computation > of index pages to be scanned in a separate function and used it in > existing code. You will notice that I have pulled up the logic of >

Re: [HACKERS] WIP: About CMake v2

On 2017-02-10 12:07:15 -0500, Robert Haas wrote: > On Mon, Jan 30, 2017 at 10:26 AM, Peter Eisentraut > wrote: > > On 1/30/17 1:28 AM, Andres Freund wrote: > >> Given that fact, I just don't buy why it's a good idea to not also > >> replace autoconf initially. >

Re: [HACKERS] removing tsearch2

On Fri, Feb 10, 2017 at 3:28 AM, Robert Haas wrote: >>> Works for me. >> >> +1 > > OK, that's three votes in favor of removing tsearch2 (from core, > anyone who wants it can maintain a copy elsewhere). +1. I'd also be in favor of either removing contrib/isn, or changing

Re: [HACKERS] removing tsearch2

On 02/10/2017 06:41 AM, David Steele wrote: > On 2/10/17 6:28 AM, Robert Haas wrote: >> On Thu, Feb 9, 2017 at 7:37 PM, Andres Freund wrote: >>> On 2017-02-09 19:19:21 -0500, Stephen Frost wrote: * Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Feb 9, 2017 at

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

Hi, On 2017-02-10 18:18:13 +0100, Markus Nullmeier wrote: > Well, if this thread of thought about hand-crafted JIT should be taken > up again by someone at some point in time, I guess it could be possible > to reuse tools that are already out there, such as "DynASM" > (

Re: [HACKERS] Parallel Index Scans

On Wed, Feb 1, 2017 at 8:20 AM, Amit Kapila wrote: >> The hunk in indexam.c looks like a leftover that can be omitted. > > It is not a leftover hunk. Earlier, the patch has the same check > btparallelrescan, but based on your comment up thread [1] (Why does >

Re: [HACKERS] Parallel Index Scans

On Thu, Feb 9, 2017 at 5:34 AM, Amit Kapila wrote: >> What about parallel CREATE INDEX? The patch currently uses >> min_parallel_relation_size as an input into the optimizer's custom >> cost model. I had wondered if that made sense. Note that another such >> input is the

Re: [HACKERS] removing tsearch2

Robert Haas writes: > That's not a bad idea, but I think it's an independent issue. If the > hacks are still needed for an external module, we shouldn't go out of > our way to remove them even if we nuke tsearch2 (but we don't need to > maintain them going forward unless

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

On 12/06/16 21:40, Andres Freund wrote: > On 2016-12-06 14:35:43 -0600, Nico Williams wrote: >> On Tue, Dec 06, 2016 at 12:27:51PM -0800, Andres Freund wrote: >>> On 2016-12-06 14:19:21 -0600, Nico Williams wrote: > I concur with your feeling that hand-rolled JIT is right out. But

Re: [HACKERS] Press Release Draft - 2016-02-09 Cumulative Update

On Wed, Feb 8, 2017 at 5:31 PM, Jim Nasby wrote: > 11 There existed a race condition /where/ if CREATE INDEX CONCURRENTLY was > called on a column that had not been indexed before, then rows that were > updated by transactions running at the same time as the CREATE

Re: [HACKERS] WIP: About CMake v2

On Mon, Jan 30, 2017 at 10:26 AM, Peter Eisentraut wrote: > On 1/30/17 1:28 AM, Andres Freund wrote: >> Given that fact, I just don't buy why it's a good idea to not also >> replace autoconf initially. > > Well, I find it a bit scary. If you do the big switch

Re: [HACKERS] removing tsearch2

On Fri, Feb 10, 2017 at 9:28 AM, Tom Lane wrote: > Robert Haas writes: >> OK, that's three votes in favor of removing tsearch2 (from core, >> anyone who wants it can maintain a copy elsewhere). Starting a new >> thread to make sure we collect all the

Re: [HACKERS] GSoC 2017

The expected result for this work is push-based executor working for many types of queries (currently we aim at TPC-H), but it's unlikely to be a production-ready patch to commit into mainline at that stage. This work is the actual topic for our student's thesis, so he has already started, and has

Re: [HACKERS] removing tsearch2

On 2/10/17 6:28 AM, Robert Haas wrote: > On Thu, Feb 9, 2017 at 7:37 PM, Andres Freund wrote: >> On 2017-02-09 19:19:21 -0500, Stephen Frost wrote: >>> * Robert Haas (robertmh...@gmail.com) wrote: On Thu, Feb 9, 2017 at 4:24 PM, Tom Lane wrote: >

Re: [HACKERS] removing tsearch2

On Fri, Feb 10, 2017 at 2:28 PM, Robert Haas wrote: > On Thu, Feb 9, 2017 at 7:37 PM, Andres Freund wrote: > > On 2017-02-09 19:19:21 -0500, Stephen Frost wrote: > >> * Robert Haas (robertmh...@gmail.com) wrote: > >> > On Thu, Feb 9, 2017 at 4:24 PM,

Re: [HACKERS] removing tsearch2

Robert Haas writes: > OK, that's three votes in favor of removing tsearch2 (from core, > anyone who wants it can maintain a copy elsewhere). Starting a new > thread to make sure we collect all the relevant votes, but I really, > really think it's past time for this to go

Re: [HACKERS] Parameterization of partial path

Robert Haas wrote: > On Thu, Feb 9, 2017 at 12:36 PM, Antonin Houska wrote: > > When looking at try_partial_hashjoin_path and try_partial_nestloop_path > > functions I'm failing to understand the comment "Parameterized partial paths > > are not

Re: [HACKERS] removing tsearch2

> On 10 Feb 2017, at 12:28, Robert Haas wrote: > > On Thu, Feb 9, 2017 at 7:37 PM, Andres Freund wrote: >> On 2017-02-09 19:19:21 -0500, Stephen Frost wrote: >>> * Robert Haas (robertmh...@gmail.com) wrote: On Thu, Feb 9, 2017 at 4:24 PM, Tom Lane

Re: [HACKERS] Passing query string to workers

On Fri, Feb 10, 2017 at 2:54 PM, Kuntal Ghosh wrote: > On Tue, Feb 7, 2017 at 10:19 AM, Rafia Sabih > wrote: >> Thanks a lot Kuntal for the review, please find attached patch for the >> revised version. > Few comments on the patch: > >

Re: [HACKERS] Parameterization of partial path

On Thu, Feb 9, 2017 at 11:36 PM, Robert Haas wrote: > On Thu, Feb 9, 2017 at 12:36 PM, Antonin Houska wrote: >> When looking at try_partial_hashjoin_path and try_partial_nestloop_path >> functions I'm failing to understand the comment "Parameterized

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Thu, Feb 9, 2017 at 6:38 PM, Thomas Munro wrote: > Here's my thought process... please tell me where I'm going wrong: > > I have been assuming that it's not enough to just deal with this when > the leader detaches on the theory that other participants will always

Re: [HACKERS] removing tsearch2

On Fri, Feb 10, 2017 at 8:28 PM, Robert Haas wrote: > On Thu, Feb 9, 2017 at 7:37 PM, Andres Freund wrote: >> On 2017-02-09 19:19:21 -0500, Stephen Frost wrote: >>> * Robert Haas (robertmh...@gmail.com) wrote: >>> > On Thu, Feb 9, 2017 at 4:24 PM, Tom

[HACKERS] removing tsearch2

On Thu, Feb 9, 2017 at 7:37 PM, Andres Freund wrote: > On 2017-02-09 19:19:21 -0500, Stephen Frost wrote: >> * Robert Haas (robertmh...@gmail.com) wrote: >> > On Thu, Feb 9, 2017 at 4:24 PM, Tom Lane wrote: >> > > Also, our experience with contrib/tsearch2

Re: [HACKERS] parallelize queries containing initplans

On Tue, Jan 31, 2017 at 4:16 PM, Amit Kapila wrote: > On Wed, Dec 28, 2016 at 5:20 PM, Amit Kapila wrote: > >> The drawback of the second approach is >> that we need to evaluate the initplan before it is actually required >> which means that we

Re: [HACKERS] GUC for cleanup indexes threshold.

On Wed, Jan 4, 2017 at 1:51 PM, Masahiko Sawada wrote: > Attached patch introduces new GUC parameter parameter > vacuum_cleanup_index_scale_factor which specifies the fraction of the > table pages containing dead tuple needed to trigger a cleaning up > indexes. The default

Re: [HACKERS] Documentation improvements for partitioning

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 how it works and added documentation that matched my experiences, correcting what you'd said and

Re: [HACKERS] Passing query string to workers

On Tue, Feb 7, 2017 at 10:19 AM, Rafia Sabih wrote: > Thanks a lot Kuntal for the review, please find attached patch for the > revised version. Few comments on the patch: There are some spacing issues in the code. For example, + estate->es_queryString = (char

[HACKERS] log_autovacuum_min_duration doesn't log VACUUMs

I guess its fairly obvious in the title, but log_autovacuum_min_duration doesn't log VACUUMs only autovacuums. What isn't obvious is why that restruction is useful. I say that it would be helpful to log all kinds of VACUUM, so we get similar output from all methods of submission. So, changes

[HACKERS] Reporting xmin from VACUUMs

We've added xmin info to pg_stat_activity and pg_stat_replication, but VACUUM doesn't yet report which xmin value it used when it ran. Small patch to add this info to VACUUM output. -- Simon Riggshttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA,

Re: [HACKERS] Documentation improvements for partitioning

On 2017/02/10 17:00, Simon Riggs wrote: > On 10 February 2017 at 07:35, Amit Langote > wrote: > >>> A final note, because I'm really familiar with partitioning on Postgres and >>> other databases, documentation which is clear to me might not be to someone >>> less

Re: [HACKERS] Documentation improvements for partitioning

On 10 February 2017 at 07:35, Amit Langote wrote: >> A final note, because I'm really familiar with partitioning on Postgres and >> other databases, documentation which is clear to me might not be to someone >> less familiar with partitioning. Maybe we want another