Re: [HACKERS] Indirect indexes

Here's v3. This one applies on top of the "interesting-attrs" patch I sent a few hours ago: https://www.postgresql.org/message-id/20161228232018.4hc66ndrzpz4g4wn@alvherre.pgsql and contains a number of bugfixes that I discovered on my own (and which therefore require no further explanation, since

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Fri, Dec 23, 2016 at 8:28 AM, Amit Kapila wrote: > The results look positive. Do you think we can conclude based on all > the tests you and Dilip have done, that we can move forward with this > patch (in particular group-update) or do you still want to do more >

Re: [HACKERS] Reporting planning time with EXPLAIN

On Wed, Dec 28, 2016 at 10:55 PM, Stephen Frost wrote: > Tom, > > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Stephen Frost writes: >> > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> >> I think it's an awful choice of name; it has nothing to do with either >> >>

Re: [HACKERS] Reporting planning time with EXPLAIN

On Wed, Dec 28, 2016 at 10:30 PM, Tom Lane wrote: > Stephen Frost writes: >> * Tom Lane (t...@sss.pgh.pa.us) wrote: >>> I think it's an awful choice of name; it has nothing to do with either >>> the functionality or the printed name of the field. > >> As

Re: [HACKERS] pg_stat_activity.waiting_start

On Wed, Dec 28, 2016 at 1:06 PM, Tom Lane wrote: > Jim Nasby writes: >> On 12/28/16 11:25 AM, Tom Lane wrote: >>> The idea of just capturing the wait start for heavyweight locks, and >>> not other lock types, still seems superior to any of the

Re: [HACKERS] Reporting planning time with EXPLAIN

On Wed, Dec 28, 2016 at 8:41 PM, Stephen Frost wrote: > * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote: >> >> One can use this option as >> >> postgres=# explain (summary on) select * from pg_class c, pg_type t >> >> where c.reltype = t.oid; >> >>

Re: [HACKERS] Duplicate node tag assignments

Amit Kapila wrote: > On Wed, Dec 28, 2016 at 10:03 PM, Tom Lane wrote: > > Or we could just abandon the manually-assigned breaks in the list > > altogether, and let NodeTags run from 1 to whatever. This would > > slightly complicate debugging, in that the numeric values of

Re: [HACKERS] Duplicate node tag assignments

On Wed, Dec 28, 2016 at 10:03 PM, Tom Lane wrote: > By chance I happened to notice that the recent partition patch pushed > us over the number of available node tags between > > T_A_Expr = 900, > > and > > T_TriggerData = 950,/* in

Re: [HACKERS] Proposal : Parallel Merge Join

On Thu, Dec 29, 2016 at 3:15 AM, Tomas Vondra wrote: > FWIW, I've done quite a bit of testing on this patch, and also on the other > patches adding parallel index scans and bitmap heap scan. I've been running > TPC-H and TPC-DS on 16GB data sets with each patch,

Re: [HACKERS] pg_stat_activity.waiting_start

On Wed, Dec 28, 2016 at 10:55 PM, Tom Lane wrote: > Jim Nasby writes: >> On 12/28/16 7:10 AM, Amit Kapila wrote: >>> Can we think of introducing new guc trace_system_waits or something >>> like that which will indicate that the sessions will report

Re: [HACKERS] Support for pg_receivexlog --format=plain|tar

On Wed, Dec 28, 2016 at 9:31 PM, Magnus Hagander wrote: > Conditional tests? It probably wouldn't hurt to have them, but that would be > something more generic (like we'd need something to actually validate it -- > but it would make sense to have a test that, with compression

[HACKERS] rewrite HeapSatisfiesHOTAndKey

Pursuant to my comments at https://www.postgresql.org/message-id/20161223192245.hx4rbrxbrwtgwj6i@alvherre.pgsql and because of a stupid bug I found in my indirect indexes patch, I rewrote (read: removed) HeapSatisfiesHOTAndKey. The replacement function HeapDetermineModifiedColumns returns a

Re: [HACKERS] Improving RLS planning

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Here's an updated version of the RLS planning patch that gets rid of >> the incorrect interaction with Query.hasRowSecurity and adjusts >> terminology as agreed. > I've spent a fair bit of time going over this

Re: [HACKERS] Proposal : Parallel Merge Join

Hi, On 12/21/2016 04:53 PM, Dilip Kumar wrote: On Wed, Dec 21, 2016 at 8:39 PM, Robert Haas wrote: Committed the refactoring patch with some mild cosmetic adjustments. Thanks.. As to the second patch: +if (jointype == JOIN_UNIQUE_INNER) +

Re: [HACKERS] Logical tape pause/resume

On Wed, Dec 21, 2016 at 4:25 AM, Heikki Linnakangas wrote: > In the meanwhile, Robert committed the cap on the number of tapes. Since > that's in, I'm not sure if the pause/resume part of this is worthwhile. > Maybe it is. I rebased my parallel tuplesort patch on top of what you

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Wed, Dec 28, 2016 at 3:41 PM, Claudio Freire wrote: >> Anyway, I found the problem that had caused segfault. >> >> for (segindex = 0; segindex <= vacrelstats->dead_tuples.last_seg; tupindex = >> 0, segindex++) >> { >> DeadTuplesSegment *seg = >>

Re: [HACKERS] merging some features from plpgsql2 project

2016-12-28 20:25 GMT+01:00 Jim Nasby : > On 12/28/16 12:51 PM, Pavel Stehule wrote: > >> Now, the incompatibility can be hard issue - it is big question if we >> lock some users on old versions because some users can save to lines of >> code. Introduction of ROW_COUNT is

Re: [HACKERS] merging some features from plpgsql2 project

On 12/28/16 12:51 PM, Pavel Stehule wrote: Now, the incompatibility can be hard issue - it is big question if we lock some users on old versions because some users can save to lines of code. Introduction of ROW_COUNT is lowly incompatibility - it can be simply detected - but for example change

Re: [HACKERS] Improving RLS planning

Stephen Frost writes: > * Dean Rasheed (dean.a.rash...@gmail.com) wrote: >> Hmm. I've not read any of the new code yet, but the fact that this >> test now reduces to a one-time filter makes it effectively useless as >> a test of qual evaluation order because it has deduced

Re: [HACKERS] merging some features from plpgsql2 project

2016-12-28 18:54 GMT+01:00 Jim Nasby : > On 12/28/16 7:16 AM, Pavel Stehule wrote: > >> >> >> 2016-12-28 5:09 GMT+01:00 Jim Nasby > >: >> >> On 12/27/16 4:56 PM, Merlin Moncure wrote: >> >> On Tue,

Re: [HACKERS] merging some features from plpgsql2 project

2016-12-28 19:23 GMT+01:00 Jim Nasby : > On 12/28/16 12:15 PM, Pavel Stehule wrote: > >> GUC are fragile - the source code and settings can be separated. >> > > *Can* be, but they don't *have* to be. That's a huge feature, not a bug. > > Our #option is more robust,

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Wed, Dec 28, 2016 at 10:26 AM, Anastasia Lubennikova wrote: > 27.12.2016 20:14, Claudio Freire: > > On Tue, Dec 27, 2016 at 10:41 AM, Anastasia Lubennikova > wrote: > > Program terminated with signal SIGSEGV, Segmentation fault. > #0

Re: [HACKERS] proposal: session server side variables

2016-12-28 19:17 GMT+01:00 Jim Nasby : > On 12/28/16 11:29 AM, Fabien COELHO wrote: > >> >> Hello Jim, >> >> 1) Variables would be completely non-transactional. [...] A solution >>> to this problem would be to provide a plpgsql equivalent to plperl or >>> plpython's

Re: [HACKERS] merging some features from plpgsql2 project

On 12/28/16 12:15 PM, Pavel Stehule wrote: GUC are fragile - the source code and settings can be separated. *Can* be, but they don't *have* to be. That's a huge feature, not a bug. Our #option is more robust, because source code holds all flags required for execution. So I would to see a

Re: [HACKERS] proposal: session server side variables

On 12/28/2016 10:17 AM, Jim Nasby wrote: > Then IMHO what needs to happen is to have a discussion on actual syntax > instead of calling into question the value of the feature. Following > this thread has been very painful because the communications have not > been very clear. Focus on grammar

Re: [HACKERS] proposal: session server side variables

On 12/28/16 11:29 AM, Fabien COELHO wrote: Hello Jim, 1) Variables would be completely non-transactional. [...] A solution to this problem would be to provide a plpgsql equivalent to plperl or plpython's session hashes. That is what I have in mind with "session variables" à la MS/MY SQL,

Re: [HACKERS] merging some features from plpgsql2 project

2016-12-28 18:54 GMT+01:00 Jim Nasby : > On 12/28/16 7:16 AM, Pavel Stehule wrote: > >> ** The real problem is that we have no mechanism for allowing a PL's >> language/syntax/API to move forward without massive backwards >> compatibility problems. ** >> >>

Re: [HACKERS] pg_stat_activity.waiting_start

Jim Nasby writes: > On 12/28/16 11:25 AM, Tom Lane wrote: >> The idea of just capturing the wait start for heavyweight locks, and >> not other lock types, still seems superior to any of the alternatives >> that have been suggested ... > Is some kind of alarm a viable

Re: [HACKERS] pg_stat_activity.waiting_start

On 12/28/16 11:25 AM, Tom Lane wrote: The idea of just capturing the wait start for heavyweight locks, and not other lock types, still seems superior to any of the alternatives that have been suggested ... Is some kind of alarm a viable option for the others? If setting the alarm is cheap,

Re: [HACKERS] merging some features from plpgsql2 project

On 12/28/16 7:16 AM, Pavel Stehule wrote: 2016-12-28 5:09 GMT+01:00 Jim Nasby >: On 12/27/16 4:56 PM, Merlin Moncure wrote: On Tue, Dec 27, 2016 at 1:54 AM, Pavel Stehule

Re: [HACKERS] merging some features from plpgsql2 project

On 12/28/16 7:16 AM, Pavel Stehule wrote: ** The real problem is that we have no mechanism for allowing a PL's language/syntax/API to move forward without massive backwards compatibility problems. ** We have not, but there are few possibilities: 1. enhance #option command 2. we

Re: [HACKERS] proposal: session server side variables

2016-12-28 17:53 GMT+01:00 Jim Nasby : > On 12/28/16 9:57 AM, Fabien COELHO wrote: > >> * Other later triggers, etc, also reference USER_IS_AUDITOR >>> >> >> The variable is not directly referenced, one would have to call >> isUserAuditor() to access the private session

Re: [HACKERS] proposal: session server side variables

Hello Jim, 1) Variables would be completely non-transactional. [...] A solution to this problem would be to provide a plpgsql equivalent to plperl or plpython's session hashes. That is what I have in mind with "session variables" à la MS/MY SQL, but at the SQL level, not PL/pgSQL level.

Re: [HACKERS] Reporting planning time with EXPLAIN

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> I think it's an awful choice of name; it has nothing to do with either > >> the functionality or the printed name of the field. > > > As an example, we might

Re: [HACKERS] pg_stat_activity.waiting_start

Jim Nasby writes: > On 12/28/16 7:10 AM, Amit Kapila wrote: >> Can we think of introducing new guc trace_system_waits or something >> like that which will indicate that the sessions will report the value >> of wait_start in pg_stat_activity? > In my experience the

Re: [HACKERS] pg_stat_activity.waiting_start

On 12/28/16 7:10 AM, Amit Kapila wrote: Can we think of introducing new guc trace_system_waits or something like that which will indicate that the sessions will report the value of wait_start in pg_stat_activity? The default value of such a parameter can be false which means wait_start will be

Re: [HACKERS] Hooks

On 12/28/16 10:43 AM, David Fetter wrote: Callbacks aren't easy to find either. Should callbacks be another chapter in the docs? That would also be nice, but I suspect that will be harder than finding all the hooks. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in

Re: [HACKERS] Hooks

On 12/27/16 11:14 PM, David Fetter wrote: Sure, but that seems like an effort somewhat orthogonal to the one I proposed, which is to get some user-facing i.e. SGML docs up for the current hooks. My point was that a (presumably small) amount of effort towards earmarking hooks in code so that a

Re: [HACKERS] Reporting planning time with EXPLAIN

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> I think it's an awful choice of name; it has nothing to do with either >> the functionality or the printed name of the field. > As an example, we might some day wish to include a summary of buffer > information

Re: [HACKERS] proposal: session server side variables

On 12/28/16 9:57 AM, Fabien COELHO wrote: * Other later triggers, etc, also reference USER_IS_AUDITOR The variable is not directly referenced, one would have to call isUserAuditor() to access the private session value, but then you can GRANT/REVOKE whatever you want on the access function.

Re: [HACKERS] Duplicate node tag assignments

Andres Freund writes: > On 2016-12-28 11:33:31 -0500, Tom Lane wrote: >> By chance I happened to notice that the recent partition patch pushed >> us over the number of available node tags between >> So I'm leaning to the second, more drastic, solution. Thoughts? >

Re: [HACKERS] Reporting planning time with EXPLAIN

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote: > >>> I am not sure whether using *summary* to print just planning time is a > >>> good idea. Another option could be SUMMARY_PLAN_TIME. > > >

Re: [HACKERS] [PATCH] Fix for documentation of timestamp type

The latest patch attachment has a couple typos in it ("storead" instead of "stored"). I interpreted the final suggestion in the thread to mean 1) default stores in microseconds 2) deprecated compile-time option stores as seconds. If these assumptions are correct then the suggestion in the

Re: [HACKERS] Hooks

On Wed, Dec 28, 2016 at 12:19:11PM +0800, Craig Ringer wrote: > On 28 December 2016 at 12:15, Jim Nasby wrote: > > > Can we reduce the scope of this to a manageable starting point? > > I'm guessing that all existing hooks share certain characteristics > > that it'd be

Re: [HACKERS] Duplicate node tag assignments

Hi, On 2016-12-28 11:33:31 -0500, Tom Lane wrote: > By chance I happened to notice that the recent partition patch pushed > us over the number of available node tags between > > T_A_Expr = 900, > So I'm leaning to the second, more drastic, solution. Thoughts? Alternatively we could add

[HACKERS] Duplicate node tag assignments

By chance I happened to notice that the recent partition patch pushed us over the number of available node tags between T_A_Expr = 900, and T_TriggerData = 950,/* in commands/trigger.h */ Specifically we now have some of the replication grammar node type codes

Re: [HACKERS] proposal: session server side variables

2016-12-28 16:57 GMT+01:00 Fabien COELHO : > > My 0.02€ to try to illustrate a possible private session variable based > implementation for this use case: > > * Session starts >> > > \c app > > * app does SELECT setup_user('user-auth-key-data', 'some-other-blob') >> > >

Re: [HACKERS] proposal: session server side variables

My 0.02€ to try to illustrate a possible private session variable based implementation for this use case: * Session starts \c app * app does SELECT setup_user('user-auth-key-data', 'some-other-blob') SELECT setup_user('fjshdfjkshfjks', 'jklfsjfklsjfk'); ** setup_user is SECURITY

Re: [HACKERS] proposal: session server side variables

2016-12-28 16:42 GMT+01:00 Fabien COELHO : > > Hello, > > Why should they? If it is a session variable, being created when needed or >>> used with the right type could be enough? >>> >> >> You cannot to trust some fuzzy object - or you have to play hard game with >> securing

Re: [HACKERS] proposal: session server side variables

Hello, Why should they? If it is a session variable, being created when needed or used with the right type could be enough? You cannot to trust some fuzzy object - or you have to play hard game with securing content - hashing, coding, decoding - it is slow, cpu intensive I'm afraid that I

Re: [HACKERS] make more use of RoleSpec struct

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Stephen Frost wrote: > > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > > > > The only functional issue might be the removal of the IsA() checks. If > > > we don't cast any Node before passing it to any of those functions, > > > there

Re: [HACKERS] Reporting planning time with EXPLAIN

Tom Lane wrote: > How about just saying that the existing TIMING option turns this on, > if it's specified without ANALYZE? Right now that combination draws > an error: > > regression=# explain (timing on) select 1; > ERROR: EXPLAIN option TIMING requires ANALYZE > > so there's no

Re: [HACKERS] make more use of RoleSpec struct

Stephen Frost wrote: > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > > The only functional issue might be the removal of the IsA() checks. If > > we don't cast any Node before passing it to any of those functions, > > there should be no problem because any misfeasance will be reported as

Re: [HACKERS] Reporting planning time with EXPLAIN

Stephen Frost writes: > * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote: >>> I am not sure whether using *summary* to print just planning time is a >>> good idea. Another option could be SUMMARY_PLAN_TIME. > Using 'summary' seems entirely reasonable to me, I think

Re: [HACKERS] Hooks

On Wed, Dec 28, 2016 at 03:07:52PM +0900, Michael Paquier wrote: > On Wed, Dec 28, 2016 at 2:14 PM, David Fetter wrote: > > Here's everything that matches ^\w+_hook$ that I've found so far in > > git master. There are very likely false positives in this list. > > > > [... long

Re: [HACKERS] make more use of RoleSpec struct

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Peter Eisentraut wrote: > > Here is a small cleanup patch to make more use of the RoleSpec > > struct/node throughout the parser to avoid casts and make the code more > > self-documenting. > > This makes sense to me. I started to do this at

Re: [HACKERS] Reporting planning time with EXPLAIN

* Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote: > >> One can use this option as > >> postgres=# explain (summary on) select * from pg_class c, pg_type t > >> where c.reltype = t.oid; > >> QUERY PLAN > >>

Re: [HACKERS] proposal: session server side variables

On 28 December 2016 at 22:04, Pavel Stehule wrote: > For security the variable should be persistent. > > If you would to do statical analyse (what you usually would), then variable > should be persistent. > > Currently the big issue of plpgsql_check is work with

Re: [HACKERS] proposal: session server side variables

2016-12-28 15:38 GMT+01:00 Fabien COELHO : > > For security the variable should be persistent. >> > > Why should they? If it is a session variable, being created when needed or > used with the right type could be enough? > You cannot to trust some fuzzy object - or you have

Re: [HACKERS] make more use of RoleSpec struct

Peter Eisentraut wrote: > Here is a small cleanup patch to make more use of the RoleSpec > struct/node throughout the parser to avoid casts and make the code more > self-documenting. This makes sense to me. I started to do this at some point when I was writing RoleSpec; eventually got annoyed

Re: [HACKERS] proposal: session server side variables

For security the variable should be persistent. Why should they? If it is a session variable, being created when needed or used with the right type could be enough? If you would to do statical analyse (what you usually would), then variable should be persistent. I do not understand what

Re: [HACKERS] proposal: session server side variables

Also, I'm not yet convinced that simple privatizable transcient/session variables would not be enough to fit the use case, [...] So... maybe? The main question then becomes how you integrate access control. For what it's worth, permissions on persistent functions could be used to control

[HACKERS] make more use of RoleSpec struct

Here is a small cleanup patch to make more use of the RoleSpec struct/node throughout the parser to avoid casts and make the code more self-documenting. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >From

Re: [HACKERS] [PATCH] Fix minor race in commit_ts SLRU truncation vs lookups

On 28/12/16 15:01, Craig Ringer wrote: > Hi all > > There's a minor race between commit_ts SLRU truncation and concurrent > commit_ts lookups, where a lookup can check the lower valid bound xid > without knowing it's already been truncated away. This would result in > a SLRU lookup error. > >

Re: [HACKERS] proposal: session server side variables

2016-12-28 15:00 GMT+01:00 Craig Ringer : > On 28 December 2016 at 21:19, Fabien COELHO wrote: > > > Also, I'm not yet convinced that simple privatizable transcient/session > > variables would not be enough to fit the use case, so that for the same > >

[HACKERS] [PATCH] Fix minor race in commit_ts SLRU truncation vs lookups

Hi all There's a minor race between commit_ts SLRU truncation and concurrent commit_ts lookups, where a lookup can check the lower valid bound xid without knowing it's already been truncated away. This would result in a SLRU lookup error. It's pretty low-harm since it's hard to trigger and the

Re: [HACKERS] proposal: session server side variables

On 28 December 2016 at 21:19, Fabien COELHO wrote: > Also, I'm not yet convinced that simple privatizable transcient/session > variables would not be enough to fit the use case, so that for the same > price there would be session variables for all, not only special ones with

Re: [HACKERS] proposal: session server side variables

2016-12-28 4:40 GMT+01:00 Craig Ringer : > Fabien, I don't really see the point of "persistent variables". What > benefit do they add over relations? > > You can add a simple function to fetch a tuple if you want it not to > look like a subquery. Do it with heap access in C

Re: [HACKERS] Reporting planning time with EXPLAIN

>> >> One can use this option as >> postgres=# explain (summary on) select * from pg_class c, pg_type t >> where c.reltype = t.oid; >> QUERY PLAN >> -- >> Hash Join (cost=17.12..35.70 rows=319

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

27.12.2016 20:14, Claudio Freire: On Tue, Dec 27, 2016 at 10:41 AM, Anastasia Lubennikova wrote: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x006941e7 in lazy_vacuum_heap (onerel=0x1ec2360, vacrelstats=0x1ef6e00) at vacuumlazy.c:1417

Re: [HACKERS] proposal: session server side variables

2016-12-28 14:19 GMT+01:00 Fabien COELHO : > > Hello Craig, > > Fabien, I don't really see the point of "persistent variables". What >> benefit do they add over relations? >> > > A relation is a set of values, a variable is a scalar with one value. > > It is always possible

Re: [HACKERS] Reporting planning time with EXPLAIN

On Wed, Dec 28, 2016 at 02:08:55PM +0100, Michael Banck wrote: > On Tue, Dec 27, 2016 at 09:26:21AM -0500, Stephen Frost wrote: > > * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote: > > > We report planning and execution time when EXPLAIN ANALYZE is issued. > > > We do not have facility to

Re: [HACKERS] proposal: session server side variables

Hello Craig, Fabien, I don't really see the point of "persistent variables". What benefit do they add over relations? A relation is a set of values, a variable is a scalar with one value. It is always possible to declare a set and use it as a singleton, but somehow it seems cleaner to ask

Re: [HACKERS] merging some features from plpgsql2 project

2016-12-28 5:09 GMT+01:00 Jim Nasby : > On 12/27/16 4:56 PM, Merlin Moncure wrote: > >> On Tue, Dec 27, 2016 at 1:54 AM, Pavel Stehule >> wrote: >> >>> First I describe my initial position. I am strongly against introduction >>> "new" language -

Re: [HACKERS] Reporting planning time with EXPLAIN

On Tue, Dec 27, 2016 at 09:26:21AM -0500, Stephen Frost wrote: > * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote: > > We report planning and execution time when EXPLAIN ANALYZE is issued. > > We do not have facility to report planning time as part EXPLAIN > > output. In order to get the

Re: [HACKERS] pg_stat_activity.waiting_start

On Sat, Dec 24, 2016 at 7:46 AM, Tom Lane wrote: > Stephen Frost writes: >> * Tom Lane (t...@sss.pgh.pa.us) wrote: >>> The difficulty with that is it'd require a gettimeofday() call for >>> every wait start. Even on platforms where those are relatively

Re: [HACKERS] Reporting planning time with EXPLAIN

On Tue, Dec 27, 2016 at 1:27 PM, Ashutosh Bapat wrote: > Hi, > We report planning and execution time when EXPLAIN ANALYZE is issued. > We do not have facility to report planning time as part EXPLAIN > output. In order to get the planning time, one has to issue

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

27.12.2016 16:54, Alvaro Herrera: Anastasia Lubennikova wrote: I ran configure using following set of flags: ./configure --enable-tap-tests --enable-cassert --enable-debug --enable-depend CFLAGS="-O0 -g3 -fno-omit-frame-pointer" And then ran make check. Here is the stacktrace: Program

Re: [HACKERS] Support for pg_receivexlog --format=plain|tar

On Wed, Dec 28, 2016 at 6:58 AM, Michael Paquier wrote: > On Wed, Dec 28, 2016 at 3:12 AM, Magnus Hagander > wrote: > > On Tue, Dec 27, 2016 at 1:16 PM, Michael Paquier < > michael.paqu...@gmail.com> > > wrote: > >> On Tue, Dec 27, 2016 at 6:34

Re: [HACKERS] parallelize queries containing subplans

On Wed, Dec 28, 2016 at 11:47 AM, Amit Kapila wrote: > > Currently, queries that have references to SubPlans or > AlternativeSubPlans are considered parallel-restricted. I think we > can lift this restriction in many cases especially when SubPlans are > parallel-safe.

Re: [HACKERS] Measuring replay lag

On Thu, Dec 22, 2016 at 10:14 AM, Thomas Munro wrote: > On Thu, Dec 22, 2016 at 2:14 AM, Fujii Masao wrote: >> I agree that the capability to measure the remote_apply lag is very useful. >> Also I want to measure the remote_write and

[HACKERS] parallelize queries containing initplans

By seeing the subject line, one might wonder why we need to consider parallelizing the queries containing initplans differently from queries containing subplans considering that I have posted a mail to achieve later a few hours back. The reason is that both are treated differently with respect to

Re: [HACKERS] BUG: pg_stat_statements query normalization issues with combined queries

Hello Tom, [...] It's touching every single utility statement type, which is not only pretty invasive in itself, but will break any pending patches that add more utility statement types. Yep, but it is limited to headers and the break is trivial... And you've not followed through on the

Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)

On 23 December 2016 at 18:00, Craig Ringer wrote: > I'll have to follow up with a patch soon, as it's Toddler o'Clock. Here we go. This patch advances oldestXid, under XidGenLock, _before_ truncating clog. txid_status() holds XidGenLock from when it tests oldestXid

Re: [HACKERS] Faster methods for getting SPI results

On 28 December 2016 at 12:32, Jim Nasby wrote: > On 12/27/16 9:10 PM, Craig Ringer wrote: >> >> On 28 December 2016 at 09:58, Jim Nasby wrote: >> >>> I've looked at this some more, and ITSM that the only way to do this >>> without >>> some

Re: [HACKERS] postgres_fdw bug in 9.6

On Wed, Dec 28, 2016 at 1:29 PM, Etsuro Fujita wrote: > On 2016/12/28 15:54, Ashutosh Bapat wrote: >> >> On Wed, Dec 28, 2016 at 9:20 AM, Etsuro Fujita >> wrote: >>> >>> On 2016/12/27 22:03, Ashutosh Bapat wrote: If

Re: [HACKERS] postgres_fdw bug in 9.6

On 2016/12/28 15:54, Ashutosh Bapat wrote: On Wed, Dec 28, 2016 at 9:20 AM, Etsuro Fujita wrote: On 2016/12/27 22:03, Ashutosh Bapat wrote: If mergejoin_allowed is true and mergeclauselist is non-NIL but hashclauselist is NIL (that's rare but there can be types