Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree

> 31 янв. 2017 г., в 9:50, Michael Paquier > написал(а): > > On Mon, Jan 30, 2017 at 4:28 PM, Andrew Borodin wrote: >> I'll summarize here my state of studying concurrent methods of page >> unlinking. >> >> GIN B-tree does not have "high

Re: [HACKERS] Multi-tenancy with RLS

On Mon, Dec 5, 2016 at 4:31 PM, Haribabu Kommi wrote: > > > On Mon, Oct 3, 2016 at 3:11 PM, Michael Paquier > wrote: > >> On Tue, Jul 19, 2016 at 3:42 PM, Haribabu Kommi >> wrote: >> > The above changes are based

Re: [HACKERS] Commit fest 2017-01 will begin soon!

On Mon, Jan 23, 2017 at 1:17 PM, Michael Paquier wrote: > As of the current score of the CF, for a total of 155 patches, 52 have > been committed, 3 rejected and 7 marked as returned with feedback. It > may look low, but actually it is not that bad by experience looking

Re: [HACKERS] multivariate statistics (v19)

On 2017/01/31 6:57, Tomas Vondra wrote: > On 01/30/2017 09:37 PM, Alvaro Herrera wrote: >> Looks good to me. I don't think we need to keep the names very short -- >> I would propose "standistinct", "stahistogram", "stadependencies". >> > > Yeah, I got annoyed by the short names too. > > This

Re: [HACKERS] Parallel bitmap heap scan

On Tue, Jan 31, 2017 at 11:17 AM, Haribabu Kommi wrote: > On Fri, Jan 27, 2017 at 5:32 PM, Dilip Kumar wrote: >> On Tue, Jan 24, 2017 at 10:18 AM, Dilip Kumar >> wrote: >> > I have changed as per the comments. 0002 and 0003

Re: [HACKERS] [PATCH] ALTER DEFAULT PRIVILEGES with GRANT/REVOKE ON SCHEMAS

On Thu, Jan 19, 2017 at 9:35 AM, Stephen Frost wrote: > Awesome, glad to hear it. This is also on my list of patches that I'm > planning to look at, just so folks know. There is a patch, no new reviews, so moved to CF 2017-03. -- Michael -- Sent via pgsql-hackers mailing

Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree

On Mon, Jan 30, 2017 at 4:28 PM, Andrew Borodin wrote: > I'll summarize here my state of studying concurrent methods of page unlinking. > > GIN B-tree does not have "high key". That means, that rightmost key on > a page is maximal for the non-leaf page. > But I do not see

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

On Tue, Jan 31, 2017 at 3:02 AM, Robert Haas wrote: > On Fri, Jan 27, 2017 at 5:34 PM, Jim Nasby wrote: >> On 1/26/17 10:11 PM, Beena Emerson wrote: >>> In that case, we could add the file location parameter. By default it >>> would store in the

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

On Tue, Jan 31, 2017 at 2:13 PM, Vitaly Burovoy wrote: > I'm almost ready to mark it as Ready for committer. > The final round. Moved to next CF with same status, waiting on author as the last patch and the last review are very fresh. -- Michael -- Sent via

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

On Sat, Jan 28, 2017 at 10:03 AM, Thomas Munro wrote: > I have broken this up into a patch series, harmonised the private vs > shared hash table code paths better and fixed many things including > the problems with rescans and regression tests mentioned upthread. >

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

On Sun, Jan 29, 2017 at 3:33 AM, Fabrízio de Royes Mello wrote: > On Sat, Jan 28, 2017 at 4:26 PM, Fabrízio de Royes Mello > wrote: >> On Fri, Jan 27, 2017 at 8:53 PM, Peter Eisentraut >> wrote: >> > >> > On

Re: [HACKERS] [PATCH] Generic type subscription

On Sat, Jan 28, 2017 at 2:31 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote: >> On 24 January 2017 at 02:07, Tom Lane wrote: >> I took an extremely quick look over the patch > > Thank you for the feedback. It took some time for me to think about all > suggestions and notes.

Re: [HACKERS] patch: function xmltable

On Tue, Jan 31, 2017 at 5:18 AM, Pavel Stehule wrote: > true, I am sorry Last status is a new patch and no reviews. On top of that this thread is quite active. So moved to next CF. Pavel, please be careful about the status of the patch on the CF app, it was set to

Re: [HACKERS] logical decoding of two-phase transactions

On Fri, Jan 27, 2017 at 8:52 AM, Craig Ringer wrote: > Now, if it's simpler to just xlog the gid at COMMIT PREPARED time when > wal_level >= logical I don't think that's the end of the world. But > since we already have almost everything we need in memory, why not > just

Re: [HACKERS] logical decoding of two-phase transactions

On Tue, Jan 31, 2017 at 3:29 PM, Michael Paquier wrote: > On Fri, Jan 27, 2017 at 8:52 AM, Craig Ringer wrote: >> Now, if it's simpler to just xlog the gid at COMMIT PREPARED time when >> wal_level >= logical I don't think that's the end of the

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

Bonjour Michaël, Attached are the patch, a test script for the feature, and various test scripts to trigger error cases. I have moved this patch to next CF Ok. as the last status is a new patch set with no further reviews. Indeed. I did not check if the comments have been applied

Re: [HACKERS] identity columns

On Thu, Jan 5, 2017 at 9:34 AM, Vitaly Burovoy wrote: > I apologize for a silence since the last CF. > I've tested your last patch and have several nitpickings: Last update is a review from 3 weeks ago, this patch is marked as returned with feedback. -- Michael --

Re: [HACKERS] Re: new set of psql patches for loading (saving) data from (to) text, binary files

On Wed, Jan 11, 2017 at 12:32 AM, Pavel Stehule wrote: > Thank you for review Moved to next CF 2017-03. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

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

On Sat, Jan 7, 2017 at 6:25 PM, Fabien COELHO wrote: > I think that I have done what you required. > > I have documented the fact that now the feature does not work if compound > commands contain empty queries, which is a very minor drawback for a pgbench > script anyway. > >

Re: [HACKERS] DROP FUNCTION of multiple functions

On Wed, Jan 18, 2017 at 2:00 PM, Michael Paquier wrote: > On Wed, Jan 18, 2017 at 5:26 AM, Peter Eisentraut > wrote: >> On 1/10/17 1:52 AM, Michael Paquier wrote: >>> I don't see any problems with 0001. >> >> I was wondering, should we

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

On Tue, Jan 31, 2017 at 2:58 PM, Pavel Stehule wrote: > I found a error - I sent mail only to author 2016-12-31 :( - It is my > mistake. I am sorry Ah... Thanks for the update. No problem. -- Michael -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Speedup twophase transactions

On Tue, Jan 31, 2017 at 2:58 PM, Nikhil Sontakke wrote: >>> CheckPointTwoPhase() in (5) does not sync this prepared transaction >>> because the checkpointer's KnownPreparedList is empty. >> >> And that's why this needs to be stored in shared memory with a number >> of

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

This is code lifted from variable.c's ParseVariableBool(). When the other patch for "psql hooks" is committed (the one that detects when the string wasn't a valid boolean), this code will go away and we'll just use ParseVariableBool() again. The ParseVariableBool function has been updated,

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

2017-01-31 6:56 GMT+01:00 Michael Paquier : > On Tue, Jan 31, 2017 at 2:53 PM, Pavel Stehule > wrote: > > I tested new set of these patches and I found some regressions there - > > mentioned in my last mail. > > > > Maybe I miss new update, bit

Re: [HACKERS] Speedup twophase transactions

>> CheckPointTwoPhase() in (5) does not sync this prepared transaction >> because the checkpointer's KnownPreparedList is empty. > > And that's why this needs to be stored in shared memory with a number > of elements made of max_prepared_xacts... Yeah. Was thinking about this yesterday. How about

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

> > > > 2017-01-31 6:51 GMT+01:00 Michael Paquier : > >> >> >> The current patch status was "waiting on author", but that's incorrect >> as a new series of this patch has been sent. Please be careful with >> the status of the CF app! I am moving it to next CF with "needs

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

On Tue, Jan 31, 2017 at 2:53 PM, Pavel Stehule wrote: > I tested new set of these patches and I found some regressions there - > mentioned in my last mail. > > Maybe I miss new update, bit I don't know about it. The last update I am aware of is that saying: "lot of

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

2017-01-31 6:51 GMT+01:00 Michael Paquier : > On Tue, Dec 27, 2016 at 12:23 PM, Kyotaro HORIGUCHI > wrote: > > Hello, > > > > At Mon, 26 Dec 2016 14:24:33 +0100, Pavel Stehule < > pavel.steh...@gmail.com> wrote in

Re: [HACKERS] PoC: Partial sort

On Mon, Dec 5, 2016 at 2:04 PM, Haribabu Kommi wrote: > > > On Fri, Dec 2, 2016 at 4:05 AM, Robert Haas wrote: >> >> On Tue, Sep 13, 2016 at 4:32 AM, Alexander Korotkov >> wrote: >> > On Fri, Apr 8, 2016 at 10:09 PM, Peter

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

On Tue, Dec 27, 2016 at 12:23 PM, Kyotaro HORIGUCHI wrote: > Hello, > > At Mon, 26 Dec 2016 14:24:33 +0100, Pavel Stehule > wrote in > pavel.stehule> 2016-12-26 9:40

Re: [HACKERS] emergency outage requiring database restart

On Wed, Jan 4, 2017 at 4:17 AM, Peter Eisentraut wrote: > It seems like everyone was generally in favor of this. I looked around > the internet for caveats but everyone was basically saying, you should > definitely do this. > > Why not for EXEC_BACKEND? > >

Re: [HACKERS] wait events for disk I/O

On Tue, Jan 31, 2017 at 8:54 AM, Michael Paquier wrote: > On Mon, Jan 30, 2017 at 10:01 PM, Rushabh Lathia > wrote: > > Attached is the patch, which extend the existing wait event > infrastructure > > to implement the wait events for the disk

Re: [HACKERS] Speedup twophase transactions

On Tue, Jan 31, 2017 at 2:34 PM, Nikhil Sontakke wrote: >>> I wonder what's the best location for this in the common case when we >>> do shutdown of standby. We could add code in XLOG_CHECKPOINT_SHUTDOWN >>> and XLOG_CHECKPOINT_ONLINE xlog_redo code path. >> >>

Re: [HACKERS] WAL consistency check facility

On Thu, Jan 5, 2017 at 2:54 PM, Kuntal Ghosh wrote: > On Wed, Dec 21, 2016 at 10:53 PM, Robert Haas wrote: > >> On a first read-through of this patch -- I have not studied it in >> detail yet -- this looks pretty good to me. One concern is that

Re: [HACKERS] Speedup twophase transactions

>> Having CheckPointTwoPhase() do the flush would mean shifting the data >> from KnownPreparedList into TwoPhaseState shmem. > > Er, no. For CheckPointTwoPhase(), at recovery what needs to be done is > to have all the entries in KnownPreparedList() flushed to disk and > have those entries removed

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

Hi Heikki, On 2016-11-22 10:56:07 -0800, Peter Geoghegan wrote: > I attach V4 of amcheck. Is there any chance you could look at the concurrency related parts of amcheck? I'd like to push this to be mergeable, but that area is a bit outside of my area of expertise... Andres -- Sent via

[HACKERS] Refactoring of replication commands using printsimple

Hi all, This is a follow up of the refactoring that has been discussed in the thread to increase the default size of WAL segments: https://www.postgresql.org/message-id/cab7npqq4hynrlq+w1jrryvsysoxuqa40pyb2uw5uqkkag4h...@mail.gmail.com The discussion has resulted in the creation of a84069d9 that

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

On Mon, Jan 30, 2017 at 8:46 PM, Thomas Munro wrote: > On Wed, Jan 4, 2017 at 12:53 PM, Peter Geoghegan wrote: >> Attached is V7 of the patch. > > I am doing some testing. First, some superficial things from first pass: > > [Various minor cosmetic

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

On 1/27/17, Haribabu Kommi wrote: > Updated patches are attached. Hello, I'm almost ready to mark it as Ready for committer. The final round. 1. >+DATA(insert OID = 774 ( macaddr8 ... >+#define MACADDR8OID 972 What does this number (972) mean? I think it should be

Re: [HACKERS] increasing the default WAL segment size

On Sat, Jan 28, 2017 at 8:04 AM, Michael Paquier wrote: > On Sat, Jan 28, 2017 at 7:29 AM, Robert Haas wrote: >> On Thu, Jan 26, 2017 at 8:53 PM, Michael Paquier >> wrote: I've not done like the most careful

Re: [HACKERS] Patch to implement pg_current_logfile() function

On Fri, Jan 20, 2017 at 10:14 PM, Michael Paquier wrote: > On Fri, Jan 20, 2017 at 10:11 PM, Alvaro Herrera > wrote: >>> diff --git a/src/backend/replication/basebackup.c >>> b/src/backend/replication/basebackup.c >> >>> @@ -148,6 +149,9 @@

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

On Mon, Dec 5, 2016 at 2:15 PM, Haribabu Kommi wrote: > Moved to next CF with " needs review" status. Same, to CF 2017-03 this time. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] An isolation test for SERIALIZABLE READ ONLY DEFERRABLE

On Thu, Jan 12, 2017 at 10:21 AM, Michael Paquier wrote: > On Thu, Jan 12, 2017 at 4:09 AM, Robert Haas wrote: >> On Tue, Jan 10, 2017 at 11:41 PM, Michael Paquier >> wrote: >>> Do you think that expanding the wait

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

On Wed, Jan 4, 2017 at 12:53 PM, Peter Geoghegan wrote: > Attached is V7 of the patch. I am doing some testing. First, some superficial things from first pass: Still applies with some offsets and one easy-to-fix rejected hunk in nbtree.c (removing some #include directives and

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On Tue, Jan 17, 2017 at 4:31 PM, Michael Paquier wrote: > On Tue, Nov 29, 2016 at 1:35 PM, Michael Paquier > wrote: >> On Tue, Nov 22, 2016 at 8:35 PM, Haribabu Kommi >> wrote: >>> Hi Craig, >>> >>> This is a gentle

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On Mon, Jan 30, 2017 at 8:01 PM, Vladimir Rusinov wrote: > > On Fri, Jan 27, 2017 at 11:03 PM, Peter Eisentraut > wrote: >> >> 1. Rename nothing >> 2. Rename directory only >> 3. Rename everything > > > 3 or 1 (with a slight preference for

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

On Thu, Jan 26, 2017 at 9:11 PM, Kyotaro HORIGUCHI wrote: >> Though, I know the community is against behaviour changing GUCs. I >> will not spend more time on this, before I get positive feedback from >> others. > > That's too bad. I'm sorry that I wasn't very

Re: [HACKERS] WAL logging problem in 9.4.3?

On Fri, Dec 2, 2016 at 1:39 PM, Haribabu Kommi wrote: > The latest proposed patch still having problems. > Closed in 2016-11 commitfest with "moved to next CF" status because of a bug > fix patch. > Please feel free to update the status once you submit the updated patch.

Re: [HACKERS] Crash on promotion when recovery.conf is renamed

On Tue, Dec 20, 2016 at 4:54 PM, Michael Paquier wrote: > I am attaching that to next CF. Moved to CF 2017-03. Both patches still apply. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] multivariate statistics (v19)

On Tue, Jan 31, 2017 at 6:57 AM, Tomas Vondra wrote: > This however reminds me that perhaps pg_mv_statistic is not the best name. I > know others proposed pg_statistic_ext (and pg_stats_ext), and while I wasn't > a big fan initially, I think it's a better name.

Re: [HACKERS] pg_hba_file_settings view patch

On Tue, Jan 31, 2017 at 12:55 PM, Haribabu Kommi wrote: > > > On Tue, Jan 31, 2017 at 10:04 AM, Tom Lane wrote: >> >> Haribabu Kommi writes: >> > On Mon, Jan 30, 2017 at 5:18 PM, Michael Paquier >> >

Re: [HACKERS] COPY as a set returning function

On Tue, Jan 31, 2017 at 3:05 AM, Corey Huinker wrote: > On Fri, Jan 27, 2017 at 9:42 PM, Peter Eisentraut > wrote: >> >> On 1/25/17 8:51 PM, Corey Huinker wrote: >> > # select * from copy_srf('echo "x\ty"',true) as t(x text, y text); >>

Re: [HACKERS] pg_hba_file_settings view patch

On Tue, Jan 31, 2017 at 10:04 AM, Tom Lane wrote: > Haribabu Kommi writes: > > On Mon, Jan 30, 2017 at 5:18 PM, Michael Paquier < > michael.paqu...@gmail.com> > > wrote: > >> #define USER_AUTH_LAST uaPeer > >> StaticAssertStmt(lengthof(UserAuthName)

Re: [HACKERS] delta relations in AFTER triggers

On Sat, Jan 21, 2017 at 6:37 AM, Kevin Grittner wrote: > On Fri, Jan 20, 2017 at 2:08 PM, Nico Williams wrote: >> On Fri, Jan 20, 2017 at 01:37:33PM -0600, Kevin Grittner wrote: > >>> There is currently plenty of room for pseudo-MV implementations, >>>

Re: [HACKERS] Radix tree for character conversion

On Mon, Jan 30, 2017 at 3:37 PM, Kyotaro HORIGUCHI wrote: > Hello, this is the revised version of character conversion using radix tree. Thanks for the new version, I'll look at it once I am done with the cleanup of the current CF. For now I have moved it to the

Re: [HACKERS] wait events for disk I/O

On Mon, Jan 30, 2017 at 10:01 PM, Rushabh Lathia wrote: > Attached is the patch, which extend the existing wait event infrastructure > to implement the wait events for the disk I/O. Basically pg_stat_activity's > wait event information to show data about disk I/O as well

Re: [HACKERS] Speedup twophase transactions

On Tue, Jan 31, 2017 at 3:45 AM, Nikhil Sontakke wrote: >> --- a/src/backend/access/transam/xlog.c >> +++ b/src/backend/access/transam/xlog.c >> @@ -9573,6 +9573,7 @@ xlog_redo(XLogReaderState *record) >> (errmsg("unexpected timeline ID %u (should be

Re: [HACKERS] Parallel bitmap heap scan

On Fri, Jan 27, 2017 at 5:32 PM, Dilip Kumar wrote: > On Tue, Jan 24, 2017 at 10:18 AM, Dilip Kumar > wrote: > > I have changed as per the comments. 0002 and 0003 are changed, 0001 is > > still the same. > > 2 days back my colleague Rafia, reported

Re: [HACKERS] Potential data loss of 2PC files

On Fri, Jan 6, 2017 at 9:26 PM, Ashutosh Bapat wrote: > On Wed, Jan 4, 2017 at 12:16 PM, Michael Paquier > wrote: >> On Wed, Jan 4, 2017 at 1:23 PM, Ashutosh Bapat >> wrote: >>> I don't have anything

Re: [HACKERS] Potential data loss of 2PC files

On Mon, Jan 30, 2017 at 10:52 PM, Heikki Linnakangas wrote: > So, if I understood correctly, the problem scenario is: > > 1. Create and write to a file. > 2. fsync() the file. > 3. Crash. > 4. After restart, the file is gone. Yes, that's a problem with fsync's durability, and we

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

On Mon, Jan 30, 2017 at 5:51 AM, Masahiko Sawada wrote: > > * We are willing to use at most maintenance_work_mem (or perhaps > * autovacuum_work_mem) memory space to keep track of dead tuples. We > * initially allocate an array of TIDs of that size, with an upper

[HACKERS] Fix handling of ALTER DEFAULT PRIVILEGES

Greetings, While working through some pg_dump regression tests, I came across a bug in 9.6+ due to the changes I made to how GRANT/REVOKEs were handled. The attached describes and fixes the bug, which only impacts dumping from 9.6+ clusters, so hopefully not too many people have been impacted by

Re: [HACKERS] Allow interrupts on waiting standby

On Fri, Jan 27, 2017 at 10:17 PM, Michael Paquier wrote: > Two things I forgot in this patch: > - documentation for the new wait event > - the string for the wait event or this would show up as "???" in > pg_stat_activity. > There are no default clauses in the

Re: [HACKERS] Improvements in psql hooks for variables

"Daniel Verite" writes: > Tom Lane wrote: >> Evidently, this test script is relying on the preceding behavior that >> setting a bool variable to an empty string was equivalent to setting >> it to "true". If it's just that script I would be okay with saying >>

Re: [HACKERS] Improvements in psql hooks for variables

Tom Lane wrote: > Evidently, this test script is relying on the preceding behavior that > setting a bool variable to an empty string was equivalent to setting > it to "true". If it's just that script I would be okay with saying > "well, it's a bug in that script" ... but I'm a bit

Re: [HACKERS] Improvements in psql hooks for variables

Tom Lane wrote: > Also, if you want to argue that allowing it to change intra- > transaction is too confusing, why would we only forbid this direction > of change and not both directions? The thread "Surprising behaviour of \set AUTOCOMMIT ON" at:

Re: [HACKERS] Performance improvement for joins where outer side is unique

On 31 January 2017 at 13:10, David Rowley wrote: > I've attached a patch which implements this. Please disregards previous patch. (I forgot git commit before git diff to make the patch) I've attached the correct patch. -- David Rowley

Re: [HACKERS] Improvements in psql hooks for variables

So I pushed this, and the buildfarm members that are testing RedisFDW immediately fell over: *** /home/andrew/bf/root/HEAD/redis_fdw.build/test/expected/redis_fdw.out 2017-01-30 18:20:27.440677318 -0500 --- /home/andrew/bf/root/HEAD/redis_fdw.build/test/results/redis_fdw.out

Re: [HACKERS] Performance improvement for joins where outer side is unique

On 28 January 2017 at 05:44, Tom Lane wrote: > I wrote: >> David Rowley writes: >>> hmm. I'm having trouble understanding why this is a problem for Unique >>> joins, but not for join removal? > >> Ah, you know what, that's just mistaken. I was

Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

Andres Freund writes: > Wonder if we there's an argument to be made for implementing this > roughly similarly to split_pathtarget_at_srf - instead of injecting a > ProjectSet node we'd add a FunctionScan node below a Result node. Yeah, possibly. That would have the advantage

Re: [HACKERS] Subtle bug in "Simplify tape block format" commit

On Mon, Jan 30, 2017 at 10:01 AM, Peter Geoghegan wrote: > Let me take another look at this later today before proceeding. I want > to run it against a custom test suite I've developed. I've done so. Some more thoughts: * I don't think that this is really any less efficient than

Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

On 2017-01-30 17:24:31 -0500, Tom Lane wrote: > Make it work like Agg and WindowFunc. To wit, dump the actually special > function calls (the set-returning functions) into a list that's internal > to the FunctionScan node, and then anything above those goes into scalar > expressions in the node's

Re: [HACKERS] patch proposal

On Tue, Jan 31, 2017 at 4:49 AM, David Steele wrote: > On 1/27/17 3:19 AM, Venkata B Nagothi wrote: >> I have split the patch into two different >> pieces. One is to determine if the recovery can start at all and other >> patch deals with the incomplete recovery situation. >

[HACKERS] [PATCH] kNN for SP-GiST

Hello hackers, I'd like to present a series of patches which is a continuation of Vlad Sterzhanov's work on kNN for SP-GiST that was done for GSOC'14. Original thread: "KNN searches support for SP-GiST [GSOC'14]"

Re: [HACKERS] pg_hba_file_settings view patch

Haribabu Kommi writes: > On Mon, Jan 30, 2017 at 5:18 PM, Michael Paquier > wrote: >> #define USER_AUTH_LAST uaPeer >> StaticAssertStmt(lengthof(UserAuthName) == USER_AUTH_LAST + 1, >> "UserAuthName must include all user authentication

Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

Andres Freund writes: > On 2017-01-30 16:55:56 -0500, Tom Lane wrote: >> No, but it allows whatever looks syntactically like a function, including >> casts. IIRC, we made func_expr work that way ages ago to deflect >> complaints that it wasn't very clear why some

Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

Hi, On 2017-01-30 16:55:56 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2017-01-27 17:58:04 +0530, Rushabh Lathia wrote: > >> SELECT * > >> FROM pg_constraint pc, > >> CAST(CASE WHEN pc.contype IN ('f','u','p') THEN generate_series(1, > >> array_upper(pc.conkey, 1))

Re: [HACKERS] multivariate statistics (v19)

On 01/30/2017 09:37 PM, Alvaro Herrera wrote: Tomas Vondra wrote: The 'built' flags may be easily replaced with a check if the bytea-like columns are NULL, and the 'enabled' columns may be replaced by the array of char, just like you proposed. That'd give us a single catalog looking like

Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

Andres Freund writes: > On 2017-01-27 17:58:04 +0530, Rushabh Lathia wrote: >> SELECT * >> FROM pg_constraint pc, >> CAST(CASE WHEN pc.contype IN ('f','u','p') THEN generate_series(1, >> array_upper(pc.conkey, 1)) ELSE NULL END AS int) AS position; >> >> Above query is

Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

Hi, On 2017-01-27 17:58:04 +0530, Rushabh Lathia wrote: > Consider the below test; > > CREATE TABLE tab ( a int primary key); > > SELECT * > FROM pg_constraint pc, > CAST(CASE WHEN pc.contype IN ('f','u','p') THEN generate_series(1, > array_upper(pc.conkey, 1)) ELSE NULL END AS int) AS

Re: [HACKERS] Performance improvement for joins where outer side is unique

David Rowley writes: > On 31 January 2017 at 04:56, Tom Lane wrote: >> I'm not following. If the join removal code had reached the stage of >> making a uniqueness check, and that check had succeeded, the join would be >> gone and there would be

Re: [HACKERS] Declarative partitioning - another take

On 1/25/17 12:54 AM, Ashutosh Bapat wrote: > The documentation available at > https://www.postgresql.org/docs/devel/static/sql-createtable.html, > does not make it clear that the lower bound of a range partition is > always inclusive and the higher one is exclusive. I think a note in > section "

Re: [HACKERS] Performance improvement for joins where outer side is unique

On 31 January 2017 at 04:56, Tom Lane wrote: > David Rowley writes: >> I can make this change, but before I do I just want to point that I >> don't think what you've said here is entirely accurate. > >> Let's assume unique joins are very common

Re: [HACKERS] Improvements in psql hooks for variables

I wrote: > Rahila Syed writes: >>> +* Switching AUTOCOMMIT from OFF to ON is not allowed when inside a >>> +* transaction, because it cannot be effective until the current >>> +* transaction is ended. >> The above change in autocommit behaviour

Re: [HACKERS] multivariate statistics (v19)

Tomas Vondra wrote: > The 'built' flags may be easily replaced with a check if the bytea-like > columns are NULL, and the 'enabled' columns may be replaced by the array of > char, just like you proposed. > > That'd give us a single catalog looking like this: > > pg_mv_statistics > starelid >

Re: [HACKERS] [COMMITTERS] pgsql: test_pg_dump TAP test whitespace cleanup

Stephen Frost wrote: > Uh, after finding our perltidyrc and running with that, I have to ask, > why are we setting vertical-tightness to 2 (never break before a closing > token)? The default of 0 (always break) end up being a lot nicer when > working on lists. Stacking isolated opening/closing

Re: [HACKERS] patch: function xmltable

Hi 2017-01-30 20:38 GMT+01:00 Alvaro Herrera : > Pavel Stehule wrote: > > > I am sending new version - it is based on own executor scan node and > > tuplestore. > > > > Some now obsolete regress tests removed, some new added. > > > > The executor code (memory context

Re: [HACKERS] [COMMITTERS] pgsql: test_pg_dump TAP test whitespace cleanup

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Stephen Frost wrote: > > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > > > > This will be undone by the next perltidy run. > > > > Ugh. > > > > I certainly hope what was there before wasn't the result of a perltidy > > run as it was

Re: [HACKERS] multivariate statistics (v19)

On 01/30/2017 05:12 PM, Alvaro Herrera wrote: > Hmm. So we have a catalog pg_mv_statistics which stores two things: 1. the configuration regarding mvstats that have been requested by user via CREATE/ALTER STATISTICS 2. the actual values captured from the above, via ANALYZE I think this

Re: [HACKERS] patch proposal

On 1/27/17 3:19 AM, Venkata B Nagothi wrote: > I will be adding the tests in > src/test/recovery/t/003_recovery_targets.pl > . My tests would look more or less > similar to recovery_target_action. I do not see any of the tests added > for the parameter

Re: [HACKERS] multivariate statistics (v19)

On 01/30/2017 05:55 PM, Alvaro Herrera wrote: Minor nitpicks: Let me suggest to use get_attnum() in CreateStatistics instead of SearchSysCacheAttName for each column. Also, we use type AttrNumber for attribute numbers rather than int16. Finally in the same function you have an erroneous

Re: [HACKERS] patch: function xmltable

Pavel Stehule wrote: > I am sending new version - it is based on own executor scan node and > tuplestore. > > Some now obsolete regress tests removed, some new added. > > The executor code (memory context usage) should be cleaned little bit - but > other code should be good. I think you forgot

Re: [HACKERS] multivariate statistics (v19)

Hello, On 01/26/2017 10:03 AM, Ideriha, Takeshi wrote: Though I pointed out these typoes and so on, I believe these feedback are less priority compared to the source code itself. So please work on my feedback if you have time. I think getting the comments (and docs in general) right is

Re: [HACKERS] multivariate statistics (v19)

On 01/26/2017 10:43 AM, Dilip Kumar wrote: histograms -- + if (matches[i] == MVSTATS_MATCH_FULL) + s += mvhist->buckets[i]->ntuples; + else if (matches[i] == MVSTATS_MATCH_PARTIAL) + s += 0.5 * mvhist->buckets[i]->ntuples; Isn't it will be better that take some percentage of the

Re: [HACKERS] [COMMITTERS] pgsql: test_pg_dump TAP test whitespace cleanup

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Stephen Frost wrote: > > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > > > > This will be undone by the next perltidy run. > > > > Ugh. > > > > I certainly hope what was there before wasn't the result of a perltidy > > run as it was

Re: [HACKERS] patch: function xmltable

Hi 2017-01-25 15:07 GMT+01:00 Alvaro Herrera : > Tom Lane wrote: > > Andres Freund writes: > > > On 2017-01-24 21:32:56 -0300, Alvaro Herrera wrote: > > >> XMLTABLE is specified by the standard to return multiple rows ... but > > >> then as far as

Re: [HACKERS] VACUUM's ancillary tasks

Thomas Munro wrote: > About BRIN indexes: I couldn't find an explanation of why BRIN > indexes don't automatically create new summary tuples when you insert > a new tuple in an unsummarised page range. Is it deferred until > VACUUM time in order to untangle some otherwise unresolvable >

Re: [HACKERS] Speedup twophase transactions

> --- a/src/backend/access/transam/xlog.c > +++ b/src/backend/access/transam/xlog.c > @@ -9573,6 +9573,7 @@ xlog_redo(XLogReaderState *record) > (errmsg("unexpected timeline ID %u (should be %u) > in checkpoint record", > checkPoint.ThisTimeLineID,

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

Pavan Deolasee wrote: > On Wed, Jan 25, 2017 at 10:06 PM, Alvaro Herrera > wrote: > > > +( \ > > > + ((tup)->t_infomask2 & HEAP_LATEST_TUPLE) != 0 \ > > > +) > > > > > > +#define HeapTupleHeaderGetRootOffset(tup) \ > > > +( \ > > > +

Re: [HACKERS] Improvements in psql hooks for variables

BTW, while testing this patch I noticed that the error reports are a tad redundant: regression=# \set AUTOCOMMIT foo unrecognized value "foo" for "AUTOCOMMIT": boolean expected \set: error while setting variable regression=# The "error while setting variable" message seems entirely

  1   2   >