README.tuplock seems to have outdated information

"The minimum across all databases, in turn, is recorded in checkpoint records, and CHECKPOINT removes pg_multixact/ segments older than that value once the checkpoint record has been flushed." The above part of the paragraph in README.tuplock seems to be outdated. I think now we truncate the mult

Re: [HACKERS] Race between SELECT and ALTER TABLE NO INHERIT

Hello, At Wed, 29 Nov 2017 14:04:01 +0900, Michael Paquier wrote in > On Tue, Sep 19, 2017 at 3:04 PM, Kyotaro HORIGUCHI > wrote: > >> By the way, I will take a look at your patch when I come back from the > >> vacation. Meanwhile, I noticed that it needs another rebase after > >> 0a480502b09

Re: [HACKERS] proposal - Default namespaces for XPath expressions (PostgreSQL 11)

At Wed, 29 Nov 2017 14:33:08 +0900, Michael Paquier wrote in > On Sat, Nov 25, 2017 at 2:32 AM, Pavel Stehule > wrote: > > fixed regress test > > The last patch still applies, but did not get any reviews. > Horiguchi-san, you are marked as a reviewer of this patch. Could you > look at it? For

Re: [HACKERS] Add support for tuple routing to foreign partitions

Hi, Fujita-san! On 24.11.2017 16:03, Etsuro Fujita wrote: (2017/10/27 20:00), Etsuro Fujita wrote: Please find attached an updated version of the patch. Amit rebased this patch and sent me the rebased version off list. Thanks for that, Amit! One thing I noticed I overlooked is about this

Re: Boolean partitions syntax

On Tue, Dec 12, 2017 at 7:19 AM, Amit Langote wrote: > Hi. > > Horiguchi-san pointed out [1] on a nearby thread that the partitioning > syntax (the FOR VALUES clause) doesn't accept true and false as valid > partition bound datums, which seems to me like an oversight. Attached a > patch to fix th

Re: Learned Index

Deepak Balasubramanyam wrote: > I came across this paper making a case for indices that use machine learning > to optimise search. > > https://arxiv.org/pdf/1712.01208.pdf > > The gist seems to be to use a linear regression model or feed a tensor flow > model when a more complicated distributio

Re: [HACKERS] pg_stat_wal_write statistics view

On Mon, Nov 27, 2017 at 2:12 PM, Haribabu Kommi wrote: > > On Wed, Nov 8, 2017 at 8:46 AM, Robert Haas wrote: > >> On Tue, Nov 7, 2017 at 4:31 AM, Haribabu Kommi >> wrote: >> >> Updated patch attached. >> > Patch rebased. >> >> I think the earlier concerns about the performance impact of this a

Re: Boolean partitions syntax

On 2017/12/12 18:12, Ashutosh Bapat wrote: > On Tue, Dec 12, 2017 at 7:19 AM, Amit Langote wrote: >> Horiguchi-san pointed out [1] on a nearby thread that the partitioning >> syntax (the FOR VALUES clause) doesn't accept true and false as valid >> partition bound datums, which seems to me like an o

Re: [HACKERS] Parallel Hash take II

On Sat, Dec 2, 2017 at 3:46 PM, Andres Freund wrote: > Looking at 0004-Add-shared-tuplestores.patch > > Comments: > - I'd rename mutex to lock. Seems quite possible that we end up with shared > lockers too. Done. > - Expand "Simple mechanism for sharing tuples between backends." intro > comm

Re: [HACKERS] Partition-wise aggregation/grouping

Here are review comments for 0009 Only full aggregation is pushed on the remote server. I think we can live with that for a while but we need to be able to push down partial aggregates to the foreign server. I agree that it needs some infrastructure to serialized and deserialize the partial aggreg

Re: Parallel Index Scan vs BTP_DELETED and BTP_HALF_DEAD

On Mon, Dec 11, 2017 at 2:26 PM, Thomas Munro wrote: > On Mon, Dec 11, 2017 at 8:14 PM, Amit Kapila wrote: > >> Thanks for looking into it. I will see if we can write some test. In >> the meantime if possible, can you please request Patrick Hemmer to >> verify the attached patch? > > Our discus

Re: [HACKERS] Runtime Partition Pruning

Hi Beena, On 12/07/2017 02:22 AM, Beena Emerson wrote: I have added the partition quals that are used for pruning. PFA the updated patch. I have changed the names of variables to make it more appropriate, along with adding more code comments and doing some refactoring and other code cleanups.

Re: Fwd: [BUGS] pg_trgm word_similarity inconsistencies or bug

0002-pg-trgm-strict_word-similarity.patch – implementation of strict_word_similarity() with comments, docs and tests. The patch looks commmitable, but sometime I get *** ...pgsql/contrib/pg_trgm/expected/pg_strict_word_trgm.out 2017-12-12 14:16:55.190989000 +0300 --- .../pgsql/contrib/pg_trgm/r

Re: [HACKERS] Runtime Partition Pruning

Hello Robert, Thank you for the comments. I have started working on it. On Fri, Dec 8, 2017 at 9:27 PM, Robert Haas wrote: > On Thu, Dec 7, 2017 at 2:22 AM, Beena Emerson wrote: >> I have added the partition quals that are used for pruning. >> >> PFA the updated patch. I have changed the names o

Re: [HACKERS] Runtime Partition Pruning

On Tue, Dec 12, 2017 at 4:57 PM, Beena Emerson wrote: > Hello Robert, > Thank you for the comments. I have started working on it. > > On Fri, Dec 8, 2017 at 9:27 PM, Robert Haas wrote: >> On Thu, Dec 7, 2017 at 2:22 AM, Beena Emerson >> wrote: >>> I have added the partition quals that are used

Re: Fwd: [BUGS] pg_trgm word_similarity inconsistencies or bug

0002-pg-trgm-strict_word-similarity.patch – implementation of strict_word_similarity() with comments, docs and tests. After some looking in 1) repeated piece of code: + if (strategy == SimilarityStrategyNumber) + nlimit = similarity_threshold; + else if (strateg

Re: [HACKERS] Runtime Partition Pruning

Hello, On Fri, Dec 8, 2017 at 3:37 AM, David Rowley wrote: > On 7 December 2017 at 23:56, Beena Emerson wrote: >> Currently Amit's v13 patches do not apply on the HEAD and I was >> working on 487a0c1518af2f3ae2d05b7fd23d636d687f28f3 which is the last >> commit where all Amit's v13 patches applie

Re: [HACKERS] Runtime Partition Pruning

Hello Jesper, On Tue, Dec 12, 2017 at 4:04 PM, Jesper Pedersen wrote: > Hi Beena, > > On 12/07/2017 02:22 AM, Beena Emerson wrote: >> >> I have added the partition quals that are used for pruning. >> >> PFA the updated patch. I have changed the names of variables to make >> it more appropriate, a

Learned Indexes in PostgreSQL?

Hi, This is an awesome paper about a new index called "Learned Index". it's aka dense hash structure derived ("learned") from actual data. Looks very promising for certain properties [*]. Anyone already working on this in Postgres? How could this be implemented in Postgres? :Stefan [*] "The Cas

Re: [HACKERS] Custom compression methods

On Mon, 11 Dec 2017 20:53:29 +0100 Tomas Vondra wrote: > But let me play the devil's advocate for a while and question the > usefulness of this approach to compression. Some of the questions were > mentioned in the thread before, but I don't think they got the > attention they deserve. Hi. I wil

Re: [HACKERS] Proposal: Local indexes for partitioned table

David Rowley wrote: > ATTACH/REPLACE sounds fine. My objection was more about the > DETACH/ATTACH method to replace an index. So what happens if you do ALTER INDEX .. ATTACH and you already have another index in that partition that is attached to the same parent in the index? With my code, what

Re: Parallel Index Scan vs BTP_DELETED and BTP_HALF_DEAD

On Tue, Dec 12, 2017 at 4:00 PM, Kuntal Ghosh wrote: > On Mon, Dec 11, 2017 at 2:26 PM, Thomas Munro > wrote: >> On Mon, Dec 11, 2017 at 8:14 PM, Amit Kapila wrote: >> >>> Thanks for looking into it. I will see if we can write some test. In >>> the meantime if possible, can you please request

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

Hi, Thanks for the warning fix, I will also look at the cassert case soon. I have been adding more test cases to this patch. I added a TAP test which now allows us to do a concurrent ROLLBACK PREPARED when the walsender is in the midst of decoding this very prepared transaction. Have added a "d

Re: Boolean partitions syntax

On Tue, Dec 12, 2017 at 3:13 PM, Amit Langote wrote: > On 2017/12/12 18:12, Ashutosh Bapat wrote: >> On Tue, Dec 12, 2017 at 7:19 AM, Amit Langote wrote: >>> Horiguchi-san pointed out [1] on a nearby thread that the partitioning >>> syntax (the FOR VALUES clause) doesn't accept true and false as v

Re: [HACKERS] Add support for tuple routing to foreign partitions

Hi Maksim, (2017/12/12 17:57), Maksim Milyutin wrote: Your patch already is not applied on master. Please rebase it. Done. Please find attached an updated version of the patch. Best regards, Etsuro Fujita *** a/contrib/file_fdw/input/file_fdw.source --- b/contrib/file_fdw/input/file_fdw.sour

Re: Fwd: [BUGS] pg_trgm word_similarity inconsistencies or bug

0001-pg-trgm-word-similarity-docs-improvement.patch – contains improvement to documentation of word_similarity() and related operators.  I decided to give formal definition first (what exactly it internally does), and then example and some more human-understandable description.  This patch also

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

On 12 December 2017 at 12:04, Nikhil Sontakke wrote: > This is an issue because of the way we are handling invalidations. We > don't allow ReorderBufferAddInvalidations() at COMMIT PREPARE time > since we assume that handling them at PREPARE time is enough. > Apparently, it's not enough. Not sur

Re: CUBE seems a bit confused about ORDER BY

Yes, the thing is that we change behavior of existing ~> operator.  In general, this is not good idea because it could affect existing users whose already use this operator.  Typically in such situation, we could leave existing operator as is, and invent new operator with new behavior.  However,

Re: CUBE seems a bit confused about ORDER BY

On Tue, Dec 12, 2017 at 3:49 PM, Teodor Sigaev wrote: > Yes, the thing is that we change behavior of existing ~> operator. In >> general, this is not good idea because it could affect existing users whose >> already use this operator. Typically in such situation, we could leave >> existing oper

Re: ML-based indexing ("The Case for Learned Index Structures", a paper from Google)

On Mon, Dec 11, 2017 at 11:11 PM, Nikolay Samokhvalov wrote: > Very interesting read: https://arxiv.org/abs/1712.01208 > > HN discussion: https://news.ycombinator.com/item?id=15894896 > > Some of the comments (from Twitter > https://twitter.com/schrockn/status/940037656494317568): "Jeff Dean and c

Re: [HACKERS] Proposal: Local indexes for partitioned table

On Mon, Dec 11, 2017 at 10:04 PM, Alvaro Herrera wrote: > David Rowley wrote: > >> ATTACH/REPLACE sounds fine. My objection was more about the >> DETACH/ATTACH method to replace an index. > > So what happens if you do ALTER INDEX .. ATTACH and you already have > another index in that partition tha

Re: Inconsistency in plpgsql's error context reports

On Mon, Dec 11, 2017 at 3:52 PM, Tom Lane wrote: > Here's a quick hack at that. I guess the main question that needs to be > asked is whether we're happy with plpgsql getting so much chattier > (as per all the regression test changes). > > If we're not, the alternative that could be considered is

Re: Out of date comment in cached_plan_cost

On Mon, Dec 11, 2017 at 5:00 AM, David Rowley wrote: > On 11 December 2017 at 21:39, Ashutosh Bapat > wrote: >> I don't see much difference in the old and new wording. The word >> "generally" confuses more than clarifying the cases when the planning >> cost curves do not change with the number of

Re: proposal: alternative psql commands quit and exit

On 12. 12. 2017 06:58, Tom Lane wrote: > Craig Ringer writes: >> I doubt I've ever written just "exit" or "quit" without indentation. I >> think if it requires them to be a bareword with no indentation, strictly >> ^(exit|quit)\n when isatty, then that's probably a safe and helpful choice. > FWIW,

Re: Testing Extension Upgrade Paths

On Mon, Dec 11, 2017 at 7:55 PM, Craig Ringer wrote: > On 12 December 2017 at 07:25, Michael Paquier > wrote: > >> On Tue, Dec 12, 2017 at 2:55 AM, Jeremy Finzel wrote: >> > I understand how to setup a regression suite for a postgres extension, >> but >> > what I'm not clear on from the docs is

Re: proposal: alternative psql commands quit and exit

I wouldn't exactly say -1 but it's a "meh" from me. On 8 December 2017 at 13:57, Daniel Vérité" wrote: > "How to exit from PostgreSQL command line utility: psql" > > now at 430k views and 1368 upvotes. There is also stackexchange question with 51000 views that asks how to start the postgresql cl

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Mon, Dec 11, 2017 at 5:20 AM, Masahiko Sawada wrote: >> The question I have is how would we deal with a foreign server that is >> not available for longer duration due to crash, longer network outage >> etc. Example is the foreign server crashed/got disconnected after >> PREPARE but before COMM

Re: proposal: alternative psql commands quit and exit

Someone mentioned about needing to read the documentation of vim to learn how to exit the program. I personally think exactly the same applies here, and am a bit surprised at the depth of discussion over this. When I first was new to cli programs, the only "standard" way to exit a program I found

Re: [HACKERS] Custom compression methods

Hi! Let me add my two cents too. On Tue, Dec 12, 2017 at 2:41 PM, Ildus Kurbangaliev < i.kurbangal...@postgrespro.ru> wrote: > On Mon, 11 Dec 2017 20:53:29 +0100 Tomas Vondra < > tomas.von...@2ndquadrant.com> wrote: > > Replacing the algorithm used to compress all varlena values (in a way > > th

Re: proposal: alternative psql commands quit and exit

On Tue, Dec 12, 2017 at 8:04 AM, Jeremy Finzel wrote: > I don't think this is a significant stumbling block for users adopting > postgres. > ​The OP complained, and I tend to agree, that 90% of the world uses the command "exit" to end a program and that it would be nice if we did as well. This

Re: proposal: alternative psql commands quit and exit

It takes a few hours to learn PostgreSQL and 1 second to remember, how to quit from psql. Surprised to see the depth of discussion on this. It takes sometime for a person to explore or know about PostgreSQL and install it. Likewise, it takes him some more time to understand that there exists a "ps

portal pinning

While working on transaction control in procedures, I noticed some inconsistencies in how portal pinning is used. This mechanism was introduced in eb81b6509f4c9109ecf8839d8c482cc597270687 to prevent user code from closing cursors that PL/pgSQL has created internally, mainly for FOR loops. Otherwi

Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager

On Mon, Dec 11, 2017 at 4:10 PM, Masahiko Sawada wrote: > Thank you for updating the patch. Here is two minor comments. > > + * we acquire the same relation extension lock repeatedly. nLocks is 0 is > the > + * number of times we've acquired that lock; > > Should it be "nLocks is the number of t

Re: money type's overflow handling is woefully incomplete

On Mon, Dec 11, 2017 at 5:50 PM, Andres Freund wrote: > This leads to fun like: > > postgres[2002][1]=# SELECT '92233720368547758.07'::money+'0.1'; > ┌─┐ > │ ?column? │ > ├─┤ > │ -$92,233,720,368,547,757.99 │ > └───

Re: Incorrect debug info printed in generate_partition_wise_join_paths

On Mon, Dec 11, 2017 at 9:05 PM, Etsuro Fujita wrote: > (2017/12/11 17:24), Ashutosh Bapat wrote: >> Yes, that's the correct fix. We should be printing debug information >> about the child and not the parent. > > Thanks for reviewing! Committed. -- Robert Haas EnterpriseDB: http://www.enterpris

Re: money type's overflow handling is woefully incomplete

Robert Haas writes: > Long story short, I don't think anyone cares about this enough to > spend effort fixing it. I suspect the money data type has very few > users. Somebody did contribute the effort not too long ago to install that overflow check into cash_in. So maybe somebody will step up a

Re: plpgsql test layout

On 12/11/17 19:29, Michael Paquier wrote: > If I read vcregress.pl correctly, it seems to me that you need to do > more with MSVC (see plcheck). The tests would kick if sql/ and > expected/ are found, and the test list is fetched by looking at > REGRESSION in the test files. However plpgsql code ha

Re: Boolean partitions syntax

On 12/12/17 04:12, Ashutosh Bapat wrote: > May be you should use opt_boolean_or_string instead of TRUE_P and > FALSE_P. It also supports ON and OFF, which will be bonus. But ON and OFF are not valid boolean literals in SQL. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL

Re: proposal: alternative psql commands quit and exit

On 12 December 2017 at 13:04, Jeremy Finzel wrote: > FWIW I am +1 in favor of not overcomplicating the special psql commands and > keep to the "\" standard. I find the general rule of \ starts a client command and anything else starts a server command to be very good to begin with. The 'help' is

Re: proposal: alternative psql commands quit and exit

On Tue, Dec 12, 2017 at 1:02 PM, Geoff Winkless wrote: > > There is also stackexchange question with 51000 views that asks how to > start the postgresql client. Should we rename psql to mysql to help > new users too? > No, we shouldn't but it will help a lot is postgres client have names like "po

Re: proposal: alternative psql commands quit and exit

On 12 December 2017 at 16:39, Everaldo Canuto wrote: > On Tue, Dec 12, 2017 at 1:02 PM, Geoff Winkless wrote: >> There is also stackexchange question with 51000 views that asks how to >> start the postgresql client. Should we rename psql to mysql to help >> new users too? > No, we shouldn't but

Re: proposal: alternative psql commands quit and exit

On Tue, Dec 12, 2017 at 2:39 PM, Everaldo Canuto wrote: > > As others have pointed out, there are _far_ more frustrating things >> (like the lack of SHOW CREATE [TABLE|etc]... support in the backend) >> for anyone coming from mysql that I would suggest should be addressed >> if you were serious a

Re: proposal: alternative psql commands quit and exit

On 12 December 2017 at 16:36, Arthur Nascimento wrote: > Nano keeps a cheatsheet of commands on the bottom; and it's regarded > as a fairly good editor for newcomers. Some shells have a right-hand > side status bar. I quite like this idea, although I would rather a line printed after each command

Re: ML-based indexing ("The Case for Learned Index Structures", a paper from Google)

On 12/12/2017 04:33 PM, Oleg Bartunov wrote: On Mon, Dec 11, 2017 at 11:11 PM, Nikolay Samokhvalov wrote: Very interesting read: https://arxiv.org/abs/1712.01208 HN discussion: https://news.ycombinator.com/item?id=15894896 Some of the comments (from Twitter https://twitter.com/schrockn/status

Re: Learned Index

On 12/12/2017 12:16 PM, Laurenz Albe wrote: I have read into the paper. This may be interesting or not, but the paper is very vague about its concepts and algorithms, so it's hard to tell. I'd say that the paper does not meet publication standards. For example, they say that their results were

Backfill bgworker Extension?

One of our challenges we have is that our engineers have written frameworks to backfill data in several different DSLs, and every time they adopt a new language, they maybe need to write another one. To be clear, what I mean is batch updating a large set of data in small pieces so as to avoid thin

Re: money type's overflow handling is woefully incomplete

Hi, On 2017-12-12 11:01:04 -0500, Tom Lane wrote: > Robert Haas writes: > > Long story short, I don't think anyone cares about this enough to > > spend effort fixing it. I suspect the money data type has very few > > users. I'm unfortunately not so sure :(. > Somebody did contribute the effor

Re: proposal: alternative psql commands quit and exit

On 12/12/2017 12:00 PM, Geoff Winkless wrote: > I quite like this idea, although I would rather a line printed after > each command is run: something like > > mydbname=# select ; > -- > (1 row) > > \h for help, \q for quit, \expert to turn off this message > osprey=# It seems to me that this is

Re: pgbench's expression parsing & negative numbers

On 2017-12-12 07:21:21 +0100, Fabien COELHO wrote: > > Hello Andres, > > > working on overflow correctness in pg I noticed that pgbench isn't quite > > there. I assume it won't matter terribly often, but the way it parses > > integers makes it incorrect for, at least, the negativemost number. >

Re: Using ProcSignal to get memory context stats from a running backend

On 2017-12-12 14:25:48 +0800, Craig Ringer wrote: > If we were willing to wrap variadic calls in a callback and rely on > vfprintf, we could: I don't think there's problems with relying on variadic calls, we do that in plenty places. > and let the ProcSignal based caller pass an elog wrapper ins

Re: [HACKERS] parallel.c oblivion of worker-startup failures

On Mon, Dec 11, 2017 at 10:41 PM, Amit Kapila wrote: > In particular, if the worker crashed (say somebody forcefully killed > the worker), then I think it will lead to a restart of the server. So > not sure, adding anything about that in the comment will make much > sense. I think it's dangerous

Re: Using ProcSignal to get memory context stats from a running backend

On Tue, Dec 12, 2017 at 1:50 PM, Andres Freund wrote: > I do wonder if the right thing here wouldn't be to put the result into a > dsm segment, and then return that to the UDF on the requesting > side. Logging to the server log and then have the requestor dig that out > doesn't seem particularly u

Re: Using ProcSignal to get memory context stats from a running backend

On 2017-12-12 14:04:55 -0500, Robert Haas wrote: > On Tue, Dec 12, 2017 at 1:50 PM, Andres Freund wrote: > > I do wonder if the right thing here wouldn't be to put the result into a > > dsm segment, and then return that to the UDF on the requesting > > side. Logging to the server log and then have

Re: ALTER TABLE ADD COLUMN fast default

On 12/06/2017 11:26 AM, Andrew Dunstan wrote: >> In general, you need to be thinking about this in terms of making sure >> that it's impossible to accidentally not update code that needs to be >> updated. Another example is that I noticed that some places the patch >> has s/CreateTupleDescCopy/C

Re: Using ProcSignal to get memory context stats from a running backend

On Tue, Dec 12, 2017 at 2:12 PM, Andres Freund wrote: > I agree that it's more reliable - I hope there's no meaningful safety > difference. I think you overestimate users a bit however - far from > most of them are going to be able to extract a very long log entry from > a busy log file. There's

Re: Using ProcSignal to get memory context stats from a running backend

On 2017-12-12 14:16:59 -0500, Robert Haas wrote: > On Tue, Dec 12, 2017 at 2:12 PM, Andres Freund wrote: > > I agree that it's more reliable - I hope there's no meaningful safety > > difference. I think you overestimate users a bit however - far from > > most of them are going to be able to extra

Re: Rethinking MemoryContext creation

I wrote: > I've not done any benchmarking on this yet, just confirmed that it > compiles and passes check-world. So once I'd done some benchmarking, I was a bit disappointed: I could not measure any difference anymore in "pgbench -S", and poking into other scenarios found cases that were actually

Re: Rethinking MemoryContext creation

On Tue, Dec 12, 2017 at 2:30 PM, Tom Lane wrote: > 379 CurTransactionContext was never used > 24 CurTransactionContext was used > 66978 ExprContext was never used > 17364 ExprContext was used > 11139 SPI Exec was never used >2421 SPI Exec was used > 38386 ginPlaceToPage tempor

Re: Rethinking MemoryContext creation

On 2017-12-12 14:50:37 -0500, Robert Haas wrote: > On Tue, Dec 12, 2017 at 2:30 PM, Tom Lane wrote: > > 379 CurTransactionContext was never used > > 24 CurTransactionContext was used > > 66978 ExprContext was never used > > 17364 ExprContext was used > > 11139 SPI Exec was never use

Error generating coverage report

I'm working on improving coverage and would like to generate some reports (other than the text versions) to help me find uncovered code. However, my source path and build path are not the same and I'm running into problems. This works fine and produces gcov output: $ make -C test/build/src/bin/pg

Re: [HACKERS] Custom compression methods

On Tue, Dec 12, 2017 at 6:07 PM, Alexander Korotkov wrote: > Hi! > > Let me add my two cents too. > > On Tue, Dec 12, 2017 at 2:41 PM, Ildus Kurbangaliev > wrote: >> >> On Mon, 11 Dec 2017 20:53:29 +0100 Tomas Vondra >> wrote: >> > Replacing the algorithm used to compress all varlena values (in

Re: [HACKERS] pg_stat_wal_write statistics view

On Tue, Dec 12, 2017 at 4:18 AM, Haribabu Kommi wrote: > I ran the pgbench performance after removing stats collector usage and > moving > the stats into shared memory. I find it that this stats addition doesn't > have any > overhead while collecting the stats. I ran these tests on a small machine

Re: Error generating coverage report

On 12/12/17 15:02, David Steele wrote: > I'm working on improving coverage and would like to generate some > reports (other than the text versions) to help me find uncovered code. > However, my source path and build path are not the same and I'm running > into problems. Vpath builds were one of th

Re: Backfill bgworker Extension?

On 12/12/17 13:03, Jeremy Finzel wrote: > To be clear, what I mean is batch updating a large set of data in small > pieces so as to avoid things like lock contention and replication lags.  > Sometimes these have a driving table that has the source data to update > in a destination table based on a

Re: Learned Indexes in PostgreSQL?

On Tue, Dec 12, 2017 at 6:38 AM, Stefan Keller wrote: > This is an awesome paper about a new index called "Learned Index". > it's aka dense hash structure derived ("learned") from actual data. > Looks very promising for certain properties [*]. > > Anyone already working on this in Postgres? > How

Re: proposal: alternative psql commands quit and exit

On 12 December 2017 at 18:32, Chapman Flack wrote: > It seems to me that this is very close to the Robert Haas suggestion > already discussed upthread, except that suggestion only prints the > hint message when you might need it, which I'd find less intrusive. Well "close" yes, but I like "simple

Re: Error generating coverage report

Hi Peter, On 12/12/17 3:20 PM, Peter Eisentraut wrote: make: Entering directory `/home/vagrant/test/build/src/bin/pg_basebackup' /usr/bin/lcov --gcov-tool /usr/bin/gcov -q --no-external -c -i -d . -d /postgres/src/bin/pg_basebackup -o lcov_base.info geninfo: ERROR: no .gcno files found in /post

Re: proposal: alternative psql commands quit and exit

On Tue, Dec 12, 2017 at 11:58 AM, Everaldo Canuto wrote: > Sorry to be so sarcastic on last comment but, I am a little frustrated, it > is not like this patch is big and need a lots of review, it is already done > and it takes 15 minutes from me and it was the first time I look at Postgres > sourc

Re: proposal: alternative psql commands quit and exit

On Tue, Dec 12, 2017 at 10:02 AM, Geoff Winkless wrote: > There is also stackexchange question with 51000 views that asks how to > start the postgresql client. Should we rename psql to mysql to help > new users too? That's not a serious question, and I don't know what your point is in suggesting

Re: proposal: alternative psql commands quit and exit

On Tue, Dec 12, 2017 at 3:38 PM, Geoff Winkless wrote: > Well "close" yes, but I like "simpler", and I'm not sure I like the > idea of waiting for someone to flail at the quit command before giving > them a hint. I think a patch that adds a line to every prompt for everyone all the time and has t

Re: [HACKERS] Custom compression methods

On Mon, Dec 11, 2017 at 1:06 PM, Alexander Korotkov wrote: > OK, but NOTICE that presumably unexpected table rewrite takes place could be > still useful. I'm not going to complain too much about that, but I think that's mostly a failure of expectation rather than a real problem. If the documenta

Re: Error generating coverage report

On 12/12/17 15:39, David Steele wrote: > $ make -C test/build/src/bin/pg_basebackup coverage-html > make: Entering directory `/home/vagrant/test/build/src/bin/pg_basebackup' > /usr/bin/lcov --gcov-tool /usr/bin/gcov -q --no-external -c -i -d . -d > /home/vagrant/src/src/bin/pg_basebackup -o lcov_b

Re: Rethinking MemoryContext creation

Andres Freund writes: > On 2017-12-12 14:50:37 -0500, Robert Haas wrote: >> It strikes me that a way to optimize these cases even more would be to >> postpone creating the context until it's actually needed. That might >> not always be a reasonable plan -- in particular, it occurs to me to >> thi

Re: [HACKERS] Custom compression methods

On Mon, Dec 11, 2017 at 2:53 PM, Tomas Vondra wrote: > But let me play the devil's advocate for a while and question the > usefulness of this approach to compression. Some of the questions were > mentioned in the thread before, but I don't think they got the attention > they deserve. Sure, thanks

Re: CUBE seems a bit confused about ORDER BY

On 12/12/2017 01:52 PM, Alexander Korotkov wrote: > On Tue, Dec 12, 2017 at 3:49 PM, Teodor Sigaev > wrote: > > Yes, the thing is that we change behavior of existing ~> > operator.  In general, this is not good idea because it could > affect exis

Re: plpgsql test layout

Peter Eisentraut writes: > On 12/11/17 19:29, Michael Paquier wrote: >> If I read vcregress.pl correctly, it seems to me that you need to do >> more with MSVC (see plcheck). The tests would kick if sql/ and >> expected/ are found, and the test list is fetched by looking at >> REGRESSION in the tes

Re: money type's overflow handling is woefully incomplete

Andres Freund writes: >> Robert Haas writes: >>> Long story short, I don't think anyone cares about this enough to >>> spend effort fixing it. I suspect the money data type has very few >>> users. > I'm unfortunately not so sure :(. There seem to be enough of them that we get pushback anytime

Re: money type's overflow handling is woefully incomplete

On 2017-12-12 16:47:17 -0500, Tom Lane wrote: > Really? We've got test cases that intentionally exercise overflow > in the money code? I think we could just drop such tests, until > such time as someone fixes the issue. Some parts at least (input & output), I think it's easy enough to fix those

Re: explain analyze output with parallel workers - question about meaning of information for explain.depesz.com

On Sat, Dec 9, 2017 at 5:30 AM, Amit Kapila wrote: > On Sat, Dec 9, 2017 at 1:24 AM, Robert Haas wrote: >> On Fri, Dec 8, 2017 at 5:11 AM, Amit Kapila wrote: Okay, I have adjusted the patch accordingly. I have also added a regression test which should produce the same result across di

Re: proposal: alternative psql commands quit and exit

On 12/12/2017 03:39 PM, Robert Haas wrote: > On Tue, Dec 12, 2017 at 10:02 AM, Geoff Winkless >> Ctrl-D works almost everywhere. It takes 2 seconds... > > If it really took everyone 2 seconds, this question would not be as > common as it is. ... Some years ago, I took a job at a mostly-Unix sho

Re: [HACKERS] Custom compression methods

On 12/12/2017 10:33 PM, Robert Haas wrote: > On Mon, Dec 11, 2017 at 2:53 PM, Tomas Vondra > wrote: >> But let me play the devil's advocate for a while and question the >> usefulness of this approach to compression. Some of the questions were >> mentioned in the thread before, but I don't think

Re: [HACKERS] Custom compression methods

On 12/12/2017 04:33 PM, Robert Haas wrote: > you want to upgrade your existing tables to use lz4 rather than pglz, > you can change the compression option for those columns to COMPRESS > lz4 PRESERVE pglz if you want to do it incrementally or just COMPRESS This is a thread I've only been followin

PATCH: Exclude unlogged tables from base backups

Including unlogged relations in base backups takes up space and is wasteful since they are truncated during backup recovery. The attached patches exclude unlogged relations from base backups except for the init fork, which is required to recreate the main fork during recovery. * exclude-unlo

Re: PATCH: Exclude unlogged tables from base backups

Hi, On 2017-12-12 17:49:54 -0500, David Steele wrote: > Including unlogged relations in base backups takes up space and is wasteful > since they are truncated during backup recovery. > > The attached patches exclude unlogged relations from base backups except for > the init fork, which is require

Re: PATCH: Exclude unlogged tables from base backups

Hi Andres, On 12/12/17 5:52 PM, Andres Freund wrote: On 2017-12-12 17:49:54 -0500, David Steele wrote: Including unlogged relations in base backups takes up space and is wasteful since they are truncated during backup recovery. The attached patches exclude unlogged relations from base backups

Re: PATCH: Exclude unlogged tables from base backups

Hi, On 2017-12-12 18:04:44 -0500, David Steele wrote: > On 12/12/17 5:52 PM, Andres Freund wrote: > > On 2017-12-12 17:49:54 -0500, David Steele wrote: > > > Including unlogged relations in base backups takes up space and is > > > wasteful > > > since they are truncated during backup recovery. >

Re: Learned Indexes in PostgreSQL?

2017-12-12 21:26 GMT+01:00 Robert Haas : > Here are links to the other two threads: > > http://postgr.es/m/CANNMO+J1KeTSx5q5SYuwHf1v-gPRLrOZw1s7qOpqWx=3umm...@mail.gmail.com > http://postgr.es/m/caaerrx8bhiw3rgaqpolqjhyhk7ghordtke5uc9dasv1w5fz...@mail.gmail.com Thanks, Robert. My fault not having

Re: PATCH: Exclude unlogged tables from base backups

On Wed, Dec 13, 2017 at 8:04 AM, David Steele wrote: > On 12/12/17 5:52 PM, Andres Freund wrote: >> On 2017-12-12 17:49:54 -0500, David Steele wrote: >>> >>> Including unlogged relations in base backups takes up space and is >>> wasteful >>> since they are truncated during backup recovery. >>> >>>

Re: PATCH: Exclude unlogged tables from base backups

On 12/12/17 6:07 PM, Andres Freund wrote: I don't see this as any different than what happens during recovery. The unlogged forks are cleaned / re-inited before replay starts which is the same thing we are doing here. It's quite different - in the recovery case there's no other write activity

Re: Leftover reference to replacement selection 1 run case

On Fri, Dec 8, 2017 at 6:41 PM, Peter Geoghegan wrote: > While reviewing the parallel CREATE INDEX patch, I noticed that commit > 8b304b8b omitted to remove a comment that it made obsolete. > > Attached patch removes the comment. I had to think about this for a while. I could see that the commen

  1   2   >