Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

On Fri, Mar 10, 2017 at 5:16 PM, Stephen Frost wrote: > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > > On 2/24/17 16:32, Pavel Stehule wrote: > > > set EXTENDED_DESCRIBE_SORT size_desc > > > \dt+ > > > \l+ > > > \di+ > > > > > > Possible variants: schema_tabl

Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

2017-03-10 15:10 GMT+01:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > On 2/24/17 16:32, Pavel Stehule wrote: > > set EXTENDED_DESCRIBE_SORT size_desc > > \dt+ > > \l+ > > \di+ > > > > Possible variants: schema_table, table_schema, size_desc, size_asc > > I can see

Re: [HACKERS] GSOC Introduction / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

[including Mengxing Liu in response, for reasons that should become obvious below...] Hi George, On Thu, Mar 9, 2017 at 6:49 PM, George Papadrosou wrote: > my name is George Papadrosou, this is my first semester as > graduate student at Georgia Tech and would like to submit a > proposal to Goog

Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

On Fri, Mar 10, 2017 at 5:10 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2/24/17 16:32, Pavel Stehule wrote: > > set EXTENDED_DESCRIBE_SORT size_desc > > \dt+ > > \l+ > > \di+ > > > > Possible variants: schema_table, table_schema, size_desc, size_asc >

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Fri, Mar 10, 2017 at 8:02 AM, Amit Kapila wrote: > I was thinking that we will use REGBUF_NO_IMAGE flag as is used in > XLOG_HEAP2_VISIBLE record for heap buffer, that will avoid any extra > I/O and will make it safe as well. I think that makes registering the > buffer safe without setting LSN

Re: [HACKERS] Index usage for elem-contained-by-const-range clauses

Hi, Pritam! I've assigned to review this patch. On Thu, Feb 23, 2017 at 2:17 AM, Pritam Baral wrote: > The topic has been previously discussed[0] on the -performance mailing > list, > about four years ago. > > In that thread, Tom suggested[0] the planner could be made to "expand > "intcol <@ >

Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 2/24/17 16:32, Pavel Stehule wrote: > > set EXTENDED_DESCRIBE_SORT size_desc > > \dt+ > > \l+ > > \di+ > > > > Possible variants: schema_table, table_schema, size_desc, size_asc > > I can see this being useful,

Re: [HACKERS] Automatic cleanup of oldest WAL segments with pg_receivexlog

On 3/9/17 17:03, Michael Paquier wrote: > Having something like --limit-retained-segments partially addresses > it, as long as there is a way to define an automatic mode, based on > statvfs() obviously. But that is not portable/usable enough, as we have determined, I think. Have you looked into u

Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

On 2/24/17 16:32, Pavel Stehule wrote: > set EXTENDED_DESCRIBE_SORT size_desc > \dt+ > \l+ > \di+ > > Possible variants: schema_table, table_schema, size_desc, size_asc I can see this being useful, but I think it needs to be organized a little better. Sort key and sort direct

Re: [HACKERS] PATCH: psql show index with type info

* Robert Haas (robertmh...@gmail.com) wrote: > On Mon, Mar 6, 2017 at 9:30 AM, Stephen Frost wrote: > > * Amos Bird (amosb...@gmail.com) wrote: > >> Well, the prefix is used to differentiate other \d commands, like > >> this, > > > > Ah, ok, fair enough. > > > > Should we consider differentiating

Re: [HACKERS] WIP: Faster Expression Processing v4

I have also looked at the 0002 and 0003 patches, and they seem OK, but they are obviously not of much use without 0004. What is your ambition for getting 0004 reviewed and committed for PG10? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remot

Re: [HACKERS] Upgrading postmaster's log messages about bind/listen errors

Greetings, * Tels (nospam-pg-ab...@bloodgate.com) wrote: > On Thu, March 9, 2017 11:43 pm, Tom Lane wrote: > > Robert Haas writes: > >> On Thu, Mar 9, 2017 at 4:01 PM, Joe Conway wrote: > >>> +1 for making it LOG instead of DEBUG1 > > > >> I would tend to vote against that, because startup is ge

Re: [HACKERS] tzdata2017a breaks timestamptz regression test

Tom Lane wrote: > For the cases involving the America/Santiago zone, I'm a bit inclined > to just switch that to America/New_York, which seems much less likely > to get fooled with by IANA. But I'm wondering if Alvaro had a specific > reason for using the Santiago zone in those test cases. No, I

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

Hi, I notice that PQsetSingleRowMode() doesn't work when getting batch results. The function is documented as: " int PQsetSingleRowMode(PGconn *conn); This function can only be called immediately after PQsendQuery or one of its sibling functions, before any other operation on the connect

Re: [HACKERS] WIP: Faster Expression Processing v4

On 3/7/17 19:14, Andres Freund wrote: >> Why shouldn't the function itself also depend on the components of its >> return type? > Because that'd make it impossible to change the return type components - > if the return type is baked into the view that's necessary, but for a > "freestanding function

Re: [HACKERS] PATCH: Configurable file mode mask

Greetings, * Tsunakawa, Takayuki (tsunakawa.ta...@jp.fujitsu.com) wrote: > From: pgsql-hackers-ow...@postgresql.org > > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of David Steele > > PostgreSQL currently requires the file mode mask (umask) to be 0077. > > However, this precludes the pos

Re: [HACKERS] Report the number of skipped frozen pages by manual VACUUM

On 3/10/17 5:08 AM, Masahiko Sawada wrote: BTW, I think there's already a function that handles the pluralization for you. IIRC it's one of the things you can add to an ereport() call. What is the function name? A quick `git grep plural` shows errdetail_plural and errmsg_plural. -- Jim Nasby,

Re: [HACKERS] Parallel Append implementation

After giving more thought to our discussions, I have have used the Bitmapset structure in AppendPath as against having two lists one for partial and other for non-partial paths. Attached is the patch v6 that has the required changes. So accumulate_append_subpath() now also prepares the bitmapset co

Re: [HACKERS] PATCH: Configurable file mode mask

Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 2/28/17 20:58, David Steele wrote: > > This patch introduces a new initdb param, -u/-file-mode-mask, and a new > > GUC, file_mode_mask, to allow the default mode of files and directories > > in the $PGDATA directory to be mod

Re: [HACKERS] Should we cacheline align PGXACT?

On Fri, Mar 10, 2017 at 4:01 PM, Ashutosh Sharma wrote: > > I agree. Probably Simon's patch for reducing pgxact access could negate > > regression in pgxact alignment patch. > > Ashutosh, could please you run read-write and read-only tests when both > > these patches applied? > > I already had t

Re: [HACKERS] Adding support for Default partition in partitioning

>I agree that adding a new partition should not move any data out of the default. It's easy enough to set up a monitor to watch for data existing in the >default. Perhaps also adding a column to pg_partitioned_table that contains the oid of the default partition so it's easier to identify from a s

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Fri, Mar 10, 2017 at 6:21 PM, Robert Haas wrote: > On Fri, Mar 10, 2017 at 7:08 AM, Amit Kapila wrote: >> On Fri, Mar 10, 2017 at 8:49 AM, Robert Haas wrote: >>> On Thu, Mar 9, 2017 at 9:34 PM, Amit Kapila wrote: Do we really need to set LSN on this page (or mark it dirty), if so w

Re: [HACKERS] Should we cacheline align PGXACT?

Hi, > > I agree. Probably Simon's patch for reducing pgxact access could negate > regression in pgxact alignment patch. > Ashutosh, could please you run read-write and read-only tests when both > these patches applied? I already had the results with both the patches applied. But, as I was not qu

Re: [HACKERS] Gather Merge

Error coming from create_gather_merge_plan() from below condition: if (memcmp(sortColIdx, gm_plan->sortColIdx, numsortkeys * sizeof(AttrNumber)) != 0) elog(ERROR, "GatherMerge child's targetlist doesn't match GatherMerge"); Above condition checks the sort column numbers

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Fri, Mar 10, 2017 at 7:08 AM, Amit Kapila wrote: > On Fri, Mar 10, 2017 at 8:49 AM, Robert Haas wrote: >> On Thu, Mar 9, 2017 at 9:34 PM, Amit Kapila wrote: >>> Do we really need to set LSN on this page (or mark it dirty), if so >>> why? Are you worried about restoration of FPI or something

Re: [HACKERS] New CORRESPONDING clause design

Hi 2017-03-10 12:55 GMT+01:00 Pavel Stehule : > > > 2017-03-10 10:13 GMT+01:00 Surafel Temesgen : > >> Yes, you are correct it should to work on CORRESPONDING clause case. SQL >> 20nn standard draft only said each query to be of the same degree in a case >> of set operation without corresponding

Re: [HACKERS] Declarative partitioning optimization for large amount of partitions

Hi Tels, Thanks a lot for the review! > "corresponding" Fixed. > Also a question: Some one-line comments are > > /* Comment. */ > > while others are > > /* > * Comment. > */ > > Why the difference? I'm trying to follow a code stile used in a code I'm modifying. In this case I got an

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Fri, Mar 10, 2017 at 8:49 AM, Robert Haas wrote: > On Thu, Mar 9, 2017 at 9:34 PM, Amit Kapila wrote: >> Do we really need to set LSN on this page (or mark it dirty), if so >> why? Are you worried about restoration of FPI or something else? > > I haven't thought through all of the possible co

Re: [HACKERS] Enabling parallelism for queries coming from SQL or other PL functions

On Wed, Mar 8, 2017 at 1:54 AM, Robert Haas wrote: > > Here's a draft patch showing the sort of thing I have in mind. I > think it needs more work, but it gives you the idea, I hope. This is > loosely based on your pl_parallel_exec_support_v1.patch, but what I've > done here is added some flags

Re: [HACKERS] New CORRESPONDING clause design

2017-03-10 10:13 GMT+01:00 Surafel Temesgen : > Yes, you are correct it should to work on CORRESPONDING clause case. SQL > 20nn standard draft only said each query to be of the same degree in a case > of set operation without corresponding clause. The attached patch is > corrected as such .I add t

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

On Fri, Mar 10, 2017 at 11:51 AM, Tom Lane wrote: > Amit Kapila writes: >> Just to let you know that I think I have figured out the reason of >> failure. If we run the regressions with attached patch, it will make >> the regression tests fail consistently in same way. The patch just >> makes al

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

On Fri, Mar 10, 2017 at 11:43 AM, Amit Kapila wrote: > On Fri, Mar 10, 2017 at 10:51 AM, Tom Lane wrote: >> >> Also, I see clam reported in green just now, so it's not 100% >> reproducible :-( >> > > Just to let you know that I think I have figured out the reason of > failure. If we run the regr

Re: [HACKERS] Report the number of skipped frozen pages by manual VACUUM

On Fri, Mar 10, 2017 at 3:58 PM, Jim Nasby wrote: > On 3/6/17 8:34 PM, Masahiko Sawada wrote: >> >> I don't think it can say "1 frozen pages" because the number of >> skipped pages according to visibility map is always more than 32 >> (SKIP_PAGES_THRESHOLD). > > > That's just an artifact of how th

Re: [HACKERS] Parallel Append implementation

Moin, On Fri, March 10, 2017 3:24 am, Amit Khandekar wrote: > On 10 March 2017 at 12:33, Ashutosh Bapat > wrote: >> On Fri, Mar 10, 2017 at 11:33 AM, Ashutosh Bapat >> wrote: But as far as code is concerned, I think the two-list approach will turn out to be less simple if we deriv

Re: [HACKERS] Gather Merge

On Fri, Mar 10, 2017 at 4:09 PM, Kuntal Ghosh wrote: > On Fri, Mar 10, 2017 at 3:04 PM, Rushabh Lathia > wrote: > > > > > > On Fri, Mar 10, 2017 at 2:42 PM, Andreas Joseph Krogh < > andr...@visena.com> > > wrote: > >> > >> På fredag 10. mars 2017 kl. 10:09:22, skrev Rushabh Lathia > >> : > >> >

Re: [HACKERS] [PATCH] Teach Catalog.pm how many attributes there should be per DATA() line

Jeff Janes writes: > On Thu, Mar 9, 2017 at 3:20 PM, Robert Haas wrote: > >> Committed. Hopefully this doesn't contain any Perl bits that are >> sufficiently new as to cause problems for our older BF members ... I >> guess we'll see. > > Bad luck there. I'm getting this error on CentOS6.8, pe

Re: [HACKERS] Upgrading postmaster's log messages about bind/listen errors

Moin, On Thu, March 9, 2017 11:43 pm, Tom Lane wrote: > Robert Haas writes: >> On Thu, Mar 9, 2017 at 4:01 PM, Joe Conway wrote: >>> On 03/09/2017 12:27 PM, Tom Lane wrote: For good measure I also added a DEBUG1 log message reporting successful binding to a port. I'm not sure if

Re: [HACKERS] Gather Merge

På fredag 10. mars 2017 kl. 10:34:48, skrev Rushabh Lathia < rushabh.lat...@gmail.com >:     On Fri, Mar 10, 2017 at 2:42 PM, Andreas Joseph Krogh mailto:andr...@visena.com>> wrote: På fredag 10. mars 2017 kl. 10:09:22, skrev Rushabh Lathia mailto:rushabh.lat...@gm

Re: [HACKERS] Page Scan Mode in Hash Index

Hi, Ashutosh! I've assigned to review this patch. At first, I'd like to notice that I like idea and general design. Secondly, patch set don't apply cleanly to master. Please, rebase it. On Tue, Feb 14, 2017 at 8:27 AM, Ashutosh Sharma wrote: > 1) 0001-Rewrite-hash-index-scans-to-work-a-page-at

Re: [HACKERS] rename pg_log directory?

On 03/09/2017 11:25 PM, Bruce Momjian wrote: "data" and "base" where chosen because it is a "data-base", but with the pg_ prefixes it would be a pg_data_pg_base. ;-) Haha, I had not spotted that one despite always naming my data directory "data" while developing. Fun little tidbit there. An

Re: [HACKERS] Gather Merge

On Fri, Mar 10, 2017 at 2:42 PM, Andreas Joseph Krogh wrote: > På fredag 10. mars 2017 kl. 10:09:22, skrev Rushabh Lathia < > rushabh.lat...@gmail.com>: > > > > On Fri, Mar 10, 2017 at 2:33 PM, Andreas Joseph Krogh > wrote: >> >> [...] >> The execution-plan seems (unsurprisingly) to depend on da

Re: [HACKERS] Should we cacheline align PGXACT?

On Wed, Mar 1, 2017 at 6:44 PM, Ashutosh Sharma wrote: > On Wed, Mar 1, 2017 at 5:29 PM, Simon Riggs wrote: > > > > On 1 March 2017 at 04:50, Ashutosh Sharma wrote: > >> > >> On Tue, Feb 28, 2017 at 11:44 PM, Simon Riggs > wrote: > >>> > >>> On 28 February 2017 at 11:34, Ashutosh Sharma > wro

Re: [HACKERS] [PATCH]: fix bug in SP-GiST box_ops

On 10.03.2017 02:13, Tels wrote: I can't comment on the code, but the grammar on the comments caught my eye: +/* Can any range from range_box does not extend higher than this argument? */ +static bool +overLower2D(RangeBox *range_box, Range *query) +{ + return FPle(range_box->left.low, qu

Re: [HACKERS] New CORRESPONDING clause design

Yes, you are correct it should to work on CORRESPONDING clause case. SQL 20nn standard draft only said each query to be of the same degree in a case of set operation without corresponding clause. The attached patch is corrected as such .I add those new test case to regression test too Regards S

Re: [HACKERS] Gather Merge

På fredag 10. mars 2017 kl. 10:09:22, skrev Rushabh Lathia < rushabh.lat...@gmail.com >:     On Fri, Mar 10, 2017 at 2:33 PM, Andreas Joseph Krogh mailto:andr...@visena.com>> wrote: [...] The execution-plan seems (unsurprisingly) to depend on data-distribution, so

Re: [HACKERS] Gather Merge

On Fri, Mar 10, 2017 at 2:33 PM, Andreas Joseph Krogh wrote: > På fredag 10. mars 2017 kl. 09:53:47, skrev Rushabh Lathia < > rushabh.lat...@gmail.com>: > > > > On Fri, Mar 10, 2017 at 1:44 PM, Andreas Joseph Krogh > wrote: >> >> På torsdag 09. mars 2017 kl. 18:09:45, skrev Robert Haas < >> robe

Re: [HACKERS] Parallel Append implementation

On 10 March 2017 at 14:05, Ashutosh Bapat wrote: >> The need for >> num_workers=-1 will still be there for partial plans, because we need >> to set it to -1 once a worker finishes a plan. >> > > IIRC, we do that so that no other workers are assigned to it when > scanning the array of plans. But wi

Re: [HACKERS] Gather Merge

På fredag 10. mars 2017 kl. 09:53:47, skrev Rushabh Lathia < rushabh.lat...@gmail.com >:     On Fri, Mar 10, 2017 at 1:44 PM, Andreas Joseph Krogh mailto:andr...@visena.com>> wrote: På torsdag 09. mars 2017 kl. 18:09:45, skrev Robert Haas mailto:robertmh...@gmail.c

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On Fri, Mar 10, 2017 at 9:36 PM, Thomas Munro wrote: > On Wed, Mar 8, 2017 at 4:12 PM, Andres Freund wrote: >> Can you come up with an halfway realistic scenario why an index oid, not >> a table, constraint, sequence oid, would be relied upon? > > Is there an implication for SIREAD locks? Predic

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/03/08 22:36, Robert Haas wrote: > On Wed, Mar 8, 2017 at 5:36 AM, Amit Langote wrote: >>> -rel = mtstate->resultRelInfo->ri_RelationDesc; >>> +nominalRTE = rt_fetch(node->nominalRelation, estate->es_range_table); >>> +nominalRel = heap_open(nominalRTE->relid, NoLock); >>> >>> No

Re: [HACKERS] Gather Merge

On Fri, Mar 10, 2017 at 1:44 PM, Andreas Joseph Krogh wrote: > På torsdag 09. mars 2017 kl. 18:09:45, skrev Robert Haas < > robertmh...@gmail.com>: > > On Thu, Mar 9, 2017 at 11:25 AM, Rushabh Lathia > wrote: > > I don't see this failure with the patch. Even I forced the gather merge > > in the

Re: [HACKERS] Other formats in pset like markdown, rst, mediawiki

2017-03-09 20:10 GMT+01:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > This is looking pretty neat. I played around with it a bit. There are > a couple of edge cases that you need to address, I think. > Thanks, original code is very synoptical and and well prepared for adding new fo

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On Wed, Mar 8, 2017 at 4:12 PM, Andres Freund wrote: > Can you come up with an halfway realistic scenario why an index oid, not > a table, constraint, sequence oid, would be relied upon? Is there an implication for SIREAD locks? Predicate locks on index pages include the index OID in the tag. -

Re: [HACKERS] Parallel Append implementation

>>> >>> I think there is some merit in separating out non-parallel and >>> parallel plans within the same array or outside it. The current logic >>> to assign plan to a worker looks at all the plans, unnecessarily >>> hopping over the un-parallel ones after they are given to a worker. If >>> w

Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan [take-2]

Hello, On Wed, March 1, 2017 7:21 pm, Kouhei Kaigai wrote: >> I've looked at the patch, and as I'm not that familiar with the >> pg-sourcecode, >> customs and so on, this isn't a review, more like food for thought and >> all >> should be taken with a grain of salt. :) >> >> So here are a few quest

Re: [HACKERS] Need a builtin way to run all tests faster manner

On 3/7/17 9:52 PM, Magnus Hagander wrote: There have also on and off been discussions about building arbitrary patches as they are sent to the mailinglists. Doing that without any committer (or other trusted party) as a filter is a completely different challenge of course, given that it basically

Re: [HACKERS] Parallel Append implementation

On 10 March 2017 at 12:33, Ashutosh Bapat wrote: > On Fri, Mar 10, 2017 at 11:33 AM, Ashutosh Bapat > wrote: >>> >>> But as far as code is concerned, I think the two-list approach will >>> turn out to be less simple if we derive corresponding two different >>> arrays in AppendState node. Handling

Re: [HACKERS] Gather Merge

På torsdag 09. mars 2017 kl. 18:09:45, skrev Robert Haas mailto:robertmh...@gmail.com>>: On Thu, Mar 9, 2017 at 11:25 AM, Rushabh Lathia wrote: > I don't see this failure with the patch. Even I forced the gather merge > in the above query and that just working fine. > > Attaching patch, with

Re: [HACKERS] ANALYZE command progress checker

On 3/6/17 12:49 AM, Michael Paquier wrote: On Sat, Mar 4, 2017 at 5:33 AM, David Steele wrote: I think the idea of a general progress view is very valuable and there are a ton of operations it could be used for: full table scans, index rebuilds, vacuum, copy, etc. However, I feel that this pr

<    1   2