Re: Rethinking MemoryContext creation

On 11 December 2017 at 17:38, Tom Lane wrote: > Simon Riggs writes: >> On 11 December 2017 at 16:27, Tom Lane wrote: >>> For a *very* large majority of the callers of AllocSetContextCreate, >>> the context name is a simple C string constant, so we could just store >>> the pointer to it and save

Re: Boolean partitions syntax

On 2017/12/12 15:35, Amit Langote wrote: > Works for me, updated patch attached. Oops, attached the old one with the last email. Updated one really attached this time. Thanks, Amit From 318c815264b27fcbda5b83e542c6a2970f714399 Mon Sep 17 00:00:00 2001 From: amit Date: Tue, 12 Dec 2017 10:33:11

Re: Boolean partitions syntax

Hi Dilip. Thanks for the review. On 2017/12/12 15:03, Dilip Kumar 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 dat

Re: proposal: alternative psql commands quit and exit

On 12 December 2017 at 13: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 > c

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

On 12 December 2017 at 14:06, Tom Lane wrote: > > Another question is whether printing to stderr, bypassing proper > > logging!, is good enough for something like this. > > Yeah, this is an issue. MemoryContextStats is designed to print > to stderr in the (possibly vain) hope that it will work

Re: pgbench's expression parsing & negative numbers

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. It directly parses the integer input using: {digit}+

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

On 12 December 2017 at 12:43, Andres Freund wrote: > Hi, > > On 2017-12-12 11:57:41 +0800, Craig Ringer wrote: > > TL;DR: Lets add a ProcSignalReason that makes a backend > > call MemoryContextStats when it sees it and a C func that users can use > to > > set it on a proc. Sane? > > It's not unpr

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

Andres Freund writes: > On 2017-12-12 11:57:41 +0800, Craig Ringer wrote: >> TL;DR: Lets add a ProcSignalReason that makes a backend >> call MemoryContextStats when it sees it and a C func that users can use to >> set it on a proc. Sane? > It's not unproblematic. procsignal_sigusr1_handler() runs

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 t

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

On 12 December 2017 at 12:25, Tsunakawa, Takayuki < tsunakawa.ta...@jp.fujitsu.com> wrote: > From: Craig Ringer [mailto:cr...@2ndquadrant.com] > > TL;DR: Lets add a ProcSignalReason that makes a backend call > > MemoryContextStats when it sees it and a C func that users can use to set > > it on a

Re: proposal: alternative psql commands quit and exit

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, I think that the special behavior (whatever

Re: [HACKERS] A design for amcheck heapam verification

On Fri, Dec 8, 2017 at 4:37 AM, Peter Geoghegan wrote: > Here, we repeat the same test 3 times, varying only the seed value > used for each run. Thanks for the updated version! Looking at 0001, I have run a coverage test and can see all code paths covered, which is nice. It is also easier to chec

pgbench's expression parsing & negative numbers

Hi, 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. It directly parses the integer input using: {digit}+{

Re: pg_dumpall -r -c try to drop user postgres

On Tue, Dec 5, 2017 at 9:03 AM, Pavel Stehule wrote: > On Sun, Dec 3, 2017 at 3:21 PM, Pavel Stehule >> wrote: >> > I am not sure if user postgres should be removed, so it is probably bug >> > >> > pg_dumpall -r -c | grep postgres >> > >> > DROP ROLE postgres; >> > CREATE ROLE postgres; >> >> >

Re: [HACKERS] postgres_fdw super user checks

On Thu, Oct 5, 2017 at 10:16 AM, Nico Williams wrote: > On Thu, Sep 14, 2017 at 04:08:08PM -0400, Robert Haas wrote: > > On Thu, Sep 14, 2017 at 2:33 PM, Jeff Janes > wrote: > > > I think that foreign tables ought to behave as views do, where they > run as > > > the owner rather than the invoker

Re: [HACKERS] postgres_fdw super user checks

On Tue, Dec 5, 2017 at 8:35 AM, Robert Haas wrote: > On Mon, Dec 4, 2017 at 5:57 PM, Ashutosh Bapat > wrote: > > I think the real behaviour can be described as something like this: > > > > "Only superusers may connect to foreign servers without password > > authentication, so always specify the

Re: [HACKERS] postgres_fdw super user checks

On Thu, Oct 5, 2017 at 10:49 AM, Simon Riggs wrote: > On 4 October 2017 at 18:13, Jeff Janes wrote: > > > OK. And if you want the first one, you can wrap it in a view currently, > but > > if it were changed I don't know what you would do if you want the 2nd one > > (other than having every u

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

Hi, On 2017-12-12 11:57:41 +0800, Craig Ringer wrote: > TL;DR: Lets add a ProcSignalReason that makes a backend > call MemoryContextStats when it sees it and a C func that users can use to > set it on a proc. Sane? It's not unproblematic. procsignal_sigusr1_handler() runs in a signal handler, so

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

From: Craig Ringer [mailto:cr...@2ndquadrant.com] > TL;DR: Lets add a ProcSignalReason that makes a backend call > MemoryContextStats when it sees it and a C func that users can use to set > it on a proc. Sane? > So how about borrowing a ProcSignalReason entry for "dump a memory context > summary

Using ProcSignal to get memory context stats from a running backend

Hi all TL;DR: Lets add a ProcSignalReason that makes a backend call MemoryContextStats when it sees it and a C func that users can use to set it on a proc. Sane? I fairly frequently want to get a memory context dump from a running backend. It's trivial to do on a debug-enabled build (or one with

Re: BUG #14941: Vacuum crashes

On Mon, Dec 11, 2017 at 2:13 PM, Michael Paquier wrote: > On Wed, Dec 6, 2017 at 1:52 AM, Bossart, Nathan wrote: >> 0001_fix_unparenthesized_vacuum_grammar_v1.patch >> >> One VacuumStmt grammar rule allows users to specify the VACOPT_ANALYZE >> option by including an AnalyzeStmt at the end of the

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

On Tue, Dec 12, 2017 at 9:00 AM, Amit Kapila wrote: > On Mon, Dec 11, 2017 at 11:27 PM, Robert Haas wrote: >> On Sun, Dec 10, 2017 at 11:07 PM, Amit Kapila >> wrote: >>> Okay, see the attached and let me know if that suffices the need? >> >> + * Check for unexpected worker death. T

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

On Mon, Dec 11, 2017 at 11:27 PM, Robert Haas wrote: > On Sun, Dec 10, 2017 at 11:07 PM, Amit Kapila wrote: >> Okay, see the attached and let me know if that suffices the need? > > + * Check for unexpected worker death. This will ensure that if > + * the postmaster failed

Re: That mode-700 check on DATADIR again

Greetings Chapman, * Chapman Flack (c...@anastigmatix.net) wrote: > I have, more or less, this classic question: > > https://www.postgresql.org/message-id/4667C403.1070807%40t3go.de [...] > So, it seems there's at least one use case where some kind of > no_really_the_datadir_permissions_are_fin

That mode-700 check on DATADIR again

I have, more or less, this classic question: https://www.postgresql.org/message-id/4667C403.1070807%40t3go.de But I have it for a newer reason, where again it seems as if a better answer than "don't do that" might be worth having. 1. Suppose you are running PG in a VM (named pgvm just for exposi

Re: proposal: alternative psql commands quit and exit

On 12 December 2017 at 05:16, Tom Lane wrote: > Peter Eisentraut writes: > > On 12/9/17 19:28, Tom Lane wrote: > >> No, my problem with it is that there are lots of contexts where typing > >> "help" won't produce anything. Robert's proposal downthread would > >> go a long way towards fixing tha

Re: proposal: alternative psql commands quit and exit

On 12 December 2017 at 05:38, Chapman Flack wrote: > On 12/11/2017 04:16 PM, Tom Lane wrote: > > Peter Eisentraut writes: > >> No opinion on that, but if the problem is that people don't know how to > >> quit psql, then we should just put that information back into the > >> welcome message and b

Re: Incorrect debug info printed in generate_partition_wise_join_paths

(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! Best regards, Etsuro Fujita

Re: Testing Extension Upgrade Paths

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 if there is a pattern that exists > for > > testing not only th

Boolean partitions syntax

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 that. create table bools (a bool) partition by list (a); Before p

Re: User defined data types in Logical Replication

On Sun, Dec 10, 2017 at 12:33 AM, Dang Minh Huong wrote: > On 2017/12/08 13:18, Huong Dangminh wrote: > >> Hi Sawada-san, >> >>> On Thu, Dec 7, 2017 at 11:07 AM, Masahiko Sawada >>> wrote: On Thu, Dec 7, 2017 at 12:23 AM, Dang Minh Huong >>> >>> wrote: > > Hi Sawada-san, >

Re: plpgsql test layout

On Tue, Dec 12, 2017 at 5:11 AM, Tom Lane wrote: > Peter Eisentraut writes: >> On 12/7/17 15:21, Pavel Stehule wrote: >>> 2017-12-07 20:08 GMT+01:00 Peter Eisentraut >>> >> >: Here is a first attempt. > >>> looks ok > >> Any other thoughts on this? I

RE: Added PostgreSQL internals learning materials in Developer FAQ

From: Craig Ringer [mailto:cr...@2ndquadrant.com] > While we're talking wiki changes, some folks may be interested in the recent > stuff I added to the profiling with perf page > https://wiki.postgresql.org/wiki/Profiling_with_perf on using > postgres's predefined tracepoints, injecting userspace

Re: Testing Extension Upgrade Paths

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 if there is a pattern that exists for > testing not only the latest version of an extension, but also an upgraded > previous v

money type's overflow handling is woefully incomplete

Hi, The money type has overflow handling in its input function: Datum cash_in(PG_FUNCTION_ARGS) ... Cashnewvalue = (value * 10) - (*s - '0'); if (newvalue / 10 != value) ereport(ERROR,

Re: [HACKERS] static assertions in C++

Peter Eisentraut writes: > On 12/11/17 16:45, Tom Lane wrote: >> (BTW, why is it that we can't fall back on the negative-width-bitfield >> trick for old g++?) > The complaint is > error: types may not be defined in 'sizeof' expressions Hmm, well, surely there's more than one way to do that; the

Re: [HACKERS] static assertions in C++

On 12/11/17 16:45, Tom Lane wrote: >> I guess the question is whether we would rather be able to have users >> continue to use older C++ compilers, or be super picky about static >> assertions. > > Uh, what is this "continue to use" bit? We've never supported > building the backend with C++ compi

Re: [HACKERS] static assertions in C++

Peter Eisentraut writes: > On 11/29/17 10:03, Tom Lane wrote: >> Right now, we have the property that every build enforces static >> assertions, albeit with variable quality of the error messages. >> I strongly disagree that it's okay to throw that property away. >> I do think that we could put an

Re: REPLICA IDENTITY FULL

On 12/4/17 22:15, Noah Misch wrote: > While reviewing this patch, I noticed a couple of nearby defects: > > - RelationFindReplTupleSeq() says "Note that this stops on the first matching > tuple.", but that's not the case. It visits every row in the table, and it > uses the last match. The cl

Re: Jsonb transform for pl/python

Peter Eisentraut writes: > On 12/11/17 03:22, Anthony Bykov wrote: >>> Why not make this part of the plpythonu extension? It doesn't have to >>> be a separate contrib module. >> I thought about that, but the problem is that there will be no >> possibilities to create custom transform if we creat

Re: proposal: alternative psql commands quit and exit

On 12/11/2017 04:16 PM, Tom Lane wrote: > Peter Eisentraut writes: >> No opinion on that, but if the problem is that people don't know how to >> quit psql, then we should just put that information back into the >> welcome message and be done with it. > > I don't think people read the welcome mess

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

On 2017-12-11 15:55:42 -0500, Robert Haas wrote: > On Mon, Dec 11, 2017 at 3:25 PM, Andres Freund wrote: > > For me "very short periods of time" and journaled metadatachanging > > filesystem operations don't quite mesh. Language lawyering aside, this > > seems quite likely to bite us down the roa

Re: [HACKERS] static assertions in C++

On 11/29/17 10:03, Tom Lane wrote: > Right now, we have the property that every build enforces static > assertions, albeit with variable quality of the error messages. > I strongly disagree that it's okay to throw that property away. > I do think that we could put an #error here instead, and wait t

Re: Jsonb transform for pl/python

On 12/11/17 03:22, Anthony Bykov wrote: >> Why not make this part of the plpythonu extension? It doesn't have to >> be a separate contrib module. >> > Hello, > I thought about that, but the problem is that there will be no > possibilities to create custom transform if we create this extension by >

Re: proposal: alternative psql commands quit and exit

Peter Eisentraut writes: > On 12/9/17 19:28, Tom Lane wrote: >> No, my problem with it is that there are lots of contexts where typing >> "help" won't produce anything. Robert's proposal downthread would >> go a long way towards fixing that. > No opinion on that, but if the problem is that peopl

Re: proposal: alternative psql commands quit and exit

On 12/9/17 19:28, Tom Lane wrote: > Peter Eisentraut writes: >> On 12/8/17 10:19, Tom Lane wrote: >>> Meh. I never thought that the "help" business was particularly well >>> thought out, and this proposal isn't better. > >> The perhaps the fix is to revert the "help" thing? > > No, my problem w

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

On Tue, Dec 12, 2017 at 5:15 AM, Robert Haas wrote: > On Sun, Dec 10, 2017 at 11:51 PM, Masahiko Sawada > wrote: >> Attached updated version patch. Please review it. > > I went over this today; please find attached an updated version which > I propose to commit. > > Changes: > > - Various format

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

On Mon, Dec 11, 2017 at 3:25 PM, Andres Freund wrote: > For me "very short periods of time" and journaled metadatachanging > filesystem operations don't quite mesh. Language lawyering aside, this > seems quite likely to bite us down the road. > > It's imo perfectly fine to say that there's only a

Re: Inconsistency in plpgsql's error context reports

I wrote: > Robert Haas writes: >> On Sun, Dec 10, 2017 at 11:55 AM, Tom Lane wrote: >>> There seem to be two ways we could look at this. One is that the >>> new test case just needs to be rejiggered to avoid unstable output >>> ("\set VERBOSITY terse" would be the easiest way). But there is >>>

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

On Fri, Dec 8, 2017 at 2:50 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Thu, Dec 7, 2017 at 8:59 PM, Robert Haas wrote: > >> On Tue, Nov 7, 2017 at 7:51 AM, Jan Przemysław Wójcik >> wrote: >> > I'm afraid that creating a function that implements quite different >> > algorithm

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

Hi, On 2017-12-11 15:15:50 -0500, Robert Haas wrote: > +* Relation extension locks. Only one process can extend a relation at > +a time; we use a specialized lock manager for this purpose, which is > +much simpler than the regular lock manager. It is similar to the > +lightweight lock mechanism,

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

On Sun, Dec 10, 2017 at 11:51 PM, Masahiko Sawada wrote: > Attached updated version patch. Please review it. I went over this today; please find attached an updated version which I propose to commit. Changes: - Various formatting fixes, including running pgindent. - Various comment updates. -

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

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 co at GOOG just released a paper showing how machine-learned indexes can

Re: plpgsql test layout

Peter Eisentraut writes: > On 12/7/17 15:21, Pavel Stehule wrote: >> 2017-12-07 20:08 GMT+01:00 Peter Eisentraut >> > >: >>> Here is a first attempt. >> looks ok > Any other thoughts on this? If not, I'd like to commit it, give the > buildfarm a run at i

Re: [HACKERS] Transaction control in procedures

On 12/7/17 18:47, Andrew Dunstan wrote: > Referring to anonymous blocks might be a bit mystifying for some > readers, unless we note that they are invoked via DO. Added parenthetical comments. > I think this sentence should probably be worded a bit differently: > > (And of course, BEGIN and

Re: plpgsql test layout

On 12/7/17 15:21, Pavel Stehule wrote: > 2017-12-07 20:08 GMT+01:00 Peter Eisentraut > >: > > On 11/14/17 11:51, Pavel Stehule wrote: > >     One option would be to create a new test setup under > src/pl/pgsql(/src) > >     and move some of th

Re: [HACKERS] Custom compression methods

Hi, I see there's an ongoing discussion about the syntax and ALTER TABLE behavior when changing a compression method for a column. So the patch seems to be on the way to be ready in the January CF, I guess. But let me play the devil's advocate for a while and question the usefulness of this appro

Re: Rethinking MemoryContext creation

Robert Haas writes: > On Mon, Dec 11, 2017 at 12:36 PM, Tom Lane wrote: >> [ thinks... ] If we wanted to go that way, one thing we could do to >> help extension authors (and ourselves) is to define the proposed >> AllocSetContextCreate macro to include >> >> StaticAssertExpr(__builtin_cons

Re: Rethinking MemoryContext creation

On 2017-12-11 13:09:42 -0500, Tom Lane wrote: > Tomas Vondra writes: > > On 12/10/2017 04:42 PM, Tom Lane wrote: > >> Peter Geoghegan writes: > >>> On Sat, Dec 9, 2017 at 5:53 PM, Tom Lane wrote: > Overall I'm seeing about a 5% improvement in a "pgbench -S" scenario, > although that nu

Re: Rethinking MemoryContext creation

Tomas Vondra writes: > On 12/10/2017 04:42 PM, Tom Lane wrote: >> Peter Geoghegan writes: >>> On Sat, Dec 9, 2017 at 5:53 PM, Tom Lane wrote: Overall I'm seeing about a 5% improvement in a "pgbench -S" scenario, although that number is a bit shaky since the run-to-run variation is

Re: [HACKERS] Custom compression methods

On Mon, Dec 11, 2017 at 8:46 PM, Robert Haas wrote: > On Mon, Dec 11, 2017 at 12:41 PM, Alexander Korotkov > wrote: > > Thus, in your example if user would like to further change awesome > > compression for evenbetter compression, she should write. > > > > SET COMPRESSION evenbetter PRESERVE pgl

Re: Rethinking MemoryContext creation

On 12/10/2017 04:42 PM, Tom Lane wrote: > Peter Geoghegan writes: >> On Sat, Dec 9, 2017 at 5:53 PM, Tom Lane wrote: >>> Overall I'm seeing about a 5% improvement in a "pgbench -S" scenario, >>> although that number is a bit shaky since the run-to-run variation >>> is a few percent anyway. > >>

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

On Sun, Dec 10, 2017 at 11:07 PM, Amit Kapila wrote: > Okay, see the attached and let me know if that suffices the need? + * Check for unexpected worker death. This will ensure that if + * the postmaster failed to start the worker, then we don't wait + * for i

Testing Extension Upgrade Paths

Hello - I understand how to setup a regression suite for a postgres extension, but what I'm not clear on from the docs is if there is a pattern that exists for testing not only the latest version of an extension, but also an upgraded previous version. For example, I am developing version 1.1, and

Re: Mention ordered datums in PartitionBoundInfoData comment

On Mon, Dec 11, 2017 at 7:28 AM, Ashutosh Bapat wrote: > PFA updated patch. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [HACKERS] Custom compression methods

On Mon, Dec 11, 2017 at 12:41 PM, Alexander Korotkov wrote: > Thus, in your example if user would like to further change awesome > compression for evenbetter compression, she should write. > > SET COMPRESSION evenbetter PRESERVE pglz, awesome; -- full list of previous > compression methods Right.

Re: Inconsistency in plpgsql's error context reports

Robert Haas writes: > On Sun, Dec 10, 2017 at 11:55 AM, Tom Lane wrote: >> There seem to be two ways we could look at this. One is that the >> new test case just needs to be rejiggered to avoid unstable output >> ("\set VERBOSITY terse" would be the easiest way). But there is >> also room to ar

Re: Rethinking MemoryContext creation

On Mon, Dec 11, 2017 at 12:36 PM, Tom Lane wrote: > [ thinks... ] If we wanted to go that way, one thing we could do to > help extension authors (and ourselves) is to define the proposed > AllocSetContextCreate macro to include > > StaticAssertExpr(__builtin_constant_p(name)) > > on compi

Re: [HACKERS] Custom compression methods

On Mon, Dec 11, 2017 at 8:25 PM, Robert Haas wrote: > On Mon, Dec 11, 2017 at 7:55 AM, Ildus Kurbangaliev > wrote: > > On Fri, 8 Dec 2017 15:12:42 -0500 > > Robert Haas wrote: > >> Maybe a better idea is ALTER COLUMN SET COMPRESSION x1, x2, x3 ... > >> meaning that x1 is the default for new tup

Re: Inconsistency in plpgsql's error context reports

On Sun, Dec 10, 2017 at 11:55 AM, Tom Lane wrote: > There seem to be two ways we could look at this. One is that the > new test case just needs to be rejiggered to avoid unstable output > ("\set VERBOSITY terse" would be the easiest way). But there is > also room to argue that it's bad that plpg

Re: Rethinking MemoryContext creation

Robert Haas writes: > On Mon, Dec 11, 2017 at 11:59 AM, Tom Lane wrote: >> Tomas Vondra writes: >>> On 12/11/2017 05:27 PM, Tom Lane wrote: However, unless we want to run around and touch all the ~ 150 calls with constant arguments, we'd have to set things up so that the default

Re: Rethinking MemoryContext creation

Simon Riggs writes: > On 11 December 2017 at 16:27, Tom Lane wrote: >> For a *very* large majority of the callers of AllocSetContextCreate, >> the context name is a simple C string constant, so we could just store >> the pointer to it and save the space and cycles required to copy it. > Why have

Re: Rethinking MemoryContext creation

On 12/11/2017 06:22 PM, Robert Haas wrote: > On Mon, Dec 11, 2017 at 11:59 AM, Tom Lane wrote: >> Tomas Vondra writes: >>> On 12/11/2017 05:27 PM, Tom Lane wrote: However, unless we want to run around and touch all the ~ 150 calls with constant arguments, we'd have to set things up so t

Re: Rethinking MemoryContext creation

Robert Haas writes: > On Mon, Dec 11, 2017 at 11:59 AM, Tom Lane wrote: >> Tomas Vondra writes: >>> On 12/11/2017 05:27 PM, Tom Lane wrote: However, unless we want to run around and touch all the ~ 150 calls with constant arguments, we'd have to set things up so that the default b

Re: Rethinking MemoryContext creation

On 11 December 2017 at 16:27, Tom Lane wrote: > For a *very* large majority of the callers of AllocSetContextCreate, > the context name is a simple C string constant, so we could just store > the pointer to it and save the space and cycles required to copy it. Why have the string at all in that

Re: [HACKERS] Custom compression methods

On Mon, Dec 11, 2017 at 7:55 AM, Ildus Kurbangaliev wrote: > On Fri, 8 Dec 2017 15:12:42 -0500 > Robert Haas wrote: >> Maybe a better idea is ALTER COLUMN SET COMPRESSION x1, x2, x3 ... >> meaning that x1 is the default for new tuples but x2, x3, etc. are >> still allowed if present. If you issu

Re: Rethinking MemoryContext creation

On Mon, Dec 11, 2017 at 11:59 AM, Tom Lane wrote: > Tomas Vondra writes: >> On 12/11/2017 05:27 PM, Tom Lane wrote: >>> However, unless we want to run around and touch all the ~ 150 calls >>> with constant arguments, we'd have to set things up so that the default >>> behavior for AllocSetContextC

Re: Rethinking MemoryContext creation

Tomas Vondra writes: > On 12/11/2017 05:27 PM, Tom Lane wrote: >> However, unless we want to run around and touch all the ~ 150 calls >> with constant arguments, we'd have to set things up so that the default >> behavior for AllocSetContextCreate is to not copy. This risks breaking >> callers in

Re: Rethinking MemoryContext creation

On 12/11/2017 05:27 PM, Tom Lane wrote: > I wrote: >> While fooling around with a different problem, I got annoyed at how slow >> MemoryContext creation and deletion is. > > Looking at this some more, there's another micro-optimization we could > make, which is to try to get rid of the strlen+st

Re: proposal: alternative psql commands quit and exit

On Mon, Dec 11, 2017 at 11:14:29AM -0200, Fabrízio de Royes Mello wrote: > And what about create some way to create aliases for meta-commands in psql? At first blush, this sounds interesting, but on further reflection, it seems more like a MASSIVE foot gun on the useability/getting help side, and

Re: Rethinking MemoryContext creation

I wrote: > While fooling around with a different problem, I got annoyed at how slow > MemoryContext creation and deletion is. Looking at this some more, there's another micro-optimization we could make, which is to try to get rid of the strlen+strcpy operations needed for the context name. (And y

Re: proposal: alternative psql commands quit and exit

Hello. On Mon, Dec 11, 2017 at 11:14 AM, Fabrízio de Royes Mello < fabriziome...@gmail.com> wrote: > > And what about create some way to create aliases for meta-commands in > psql? Something like: > > \alias quit \q > \alias exit \q > > We also can create a special config variable to enable/disab

Re: proposal: alternative psql commands quit and exit

On Sat, Dec 9, 2017 at 12:59 PM, David Fetter wrote: > > On Fri, Dec 08, 2017 at 02:12:06PM -0500, Robert Haas wrote: > > On Fri, Dec 8, 2017 at 10:28 AM, Szymon Lipiński wrote: > > > Well, if I have a new program I usually read some documentation. It really > > > helps people to exit vim as well

Re: [HACKERS] Custom compression methods

On Fri, 8 Dec 2017 15:12:42 -0500 Robert Haas wrote: > > Maybe a better idea is ALTER COLUMN SET COMPRESSION x1, x2, x3 ... > meaning that x1 is the default for new tuples but x2, x3, etc. are > still allowed if present. If you issue a command that only adds > things to the list, no table rewri

Re: Mention ordered datums in PartitionBoundInfoData comment

On Fri, Dec 8, 2017 at 12:25 AM, Robert Haas wrote: > On Tue, Dec 5, 2017 at 1:03 AM, Ashutosh Bapat > wrote: >> Sorry. Thanks for pointing it out. fixed in the attached patch. > > + * The datums in datums array are arranged in the increasing order defined by > > Suggest: in increasing order as d

Re: [HACKERS] More stats about skipped vacuums

At Mon, 27 Nov 2017 13:51:22 -0500, Robert Haas wrote in > On Mon, Nov 27, 2017 at 1:49 AM, Kyotaro HORIGUCHI > wrote: > > Hmmm. Okay, we must make stats collector more effeicient if we > > want to have additional counters with smaller significance in the > > table stats. Currently sizeof(PgSta

Re: [HACKERS] asynchronous execution

Hello, At Fri, 20 Oct 2017 17:37:07 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20171020.173707.12913619.horiguchi.kyot...@lab.ntt.co.jp> > The attached PoC patch theoretically has no impact on the normal > code paths and just brings gain in async cases. The parallel append just c

Re: After dropping the rule - Not able to insert / server crash (one time ONLY)

On Mon, Dec 11, 2017 at 3:54 PM, tushar wrote: > Hi, > > While testing something , I found that even after rule has dropped not > able to insert data and in an another scenario , there is a Crash/ > > Please refer this scenario's - > > 1) Rows not inserted after dropping the RULE > > postgres=#

After dropping the rule - Not able to insert / server crash (one time ONLY)

Hi, While testing something , I found that even after rule has dropped  not able to insert data  and in an another scenario , there is a Crash/ Please refer this scenario's - 1) Rows not inserted after dropping the RULE postgres=# create table e(n int); CREATE TABLE postgres=# create rule e1

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Tue, Nov 28, 2017 at 12:31 PM, Ashutosh Bapat wrote: > On Tue, Nov 28, 2017 at 3:04 AM, Masahiko Sawada > wrote: >> On Fri, Nov 24, 2017 at 10:28 PM, Antonin Houska wrote: >>> Masahiko Sawada wrote: >>> On Mon, Oct 30, 2017 at 5:48 PM, Ashutosh Bapat wrote: > On Thu, Oct 26,

Re: Out of date comment in cached_plan_cost

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 relations i.e. > partitions. I added that to remove the fal

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On Mon, Dec 11, 2017 at 3:16 PM, David Rowley wrote: > > Sometime in the future, I'd like to see some sort of UniqueKeys List > in RelOptInfo which is initially populated by using looking at the > unique indexes during build_simple_rel(). The idea is that these > UniqueKeys would get propagated in

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On 11 December 2017 at 22:23, Ashutosh Bapat wrote: > I think this didn't work with inheritance before partition-wise join > as well for the same reason. Yeah, I was just demonstrating a reason that the plans are not identical from querying a partitioned table when partition pruning eliminates al

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On Mon, Dec 11, 2017 at 2:42 PM, David Rowley wrote: > On 11 December 2017 at 21:18, Ashutosh Bapat > wrote: >> On Thu, Dec 7, 2017 at 5:11 AM, David Rowley >> wrote: >>> While rebasing this today I also noticed that we won't properly detect >>> unique joins in add_paths_to_joinrel() as we're st

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On 11 December 2017 at 21:18, Ashutosh Bapat wrote: > On Thu, Dec 7, 2017 at 5:11 AM, David Rowley > wrote: >> While rebasing this today I also noticed that we won't properly detect >> unique joins in add_paths_to_joinrel() as we're still testing for >> uniqueness against the partitioned parent r

Learned Index

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 distribution is needed for the data and allow SIMD instru

Re: Parallel Index Scan vs BTP_DELETED and BTP_HALF_DEAD

On Mon, Dec 11, 2017 at 8:14 PM, Amit Kapila wrote: > On Mon, Dec 11, 2017 at 8:21 AM, Thomas Munro > wrote: >> ... and then it called _bt_parallel_seize() itself, in violation of >> the rule (by my reading of the code) that you must call >> _bt_parallel_release() (via _bt_readpage()) or _bt_para

Re: [HACKERS] WAL logging problem in 9.4.3?

At Tue, 28 Nov 2017 10:36:39 +0900, Michael Paquier wrote in > On Thu, Sep 14, 2017 at 3:34 PM, Kyotaro HORIGUCHI > wrote: > > At Wed, 13 Sep 2017 17:42:39 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI > > wrote in > > <20170913.174239.25978735.horiguchi.kyot...@lab.ntt.co.jp> > >> filterdi

Re: Added PostgreSQL internals learning materials in Developer FAQ

On 11 December 2017 at 14:50, Amit Kapila wrote: > On Mon, Dec 11, 2017 at 8:43 AM, Tsunakawa, Takayuki > wrote: > > Hello, > > > > FYI > > I collected Web resources to learn PostgreSQL internals in the Developer > FAQ page. I did this because I need to provide self-education materials > for ne

Re: Out of date comment in cached_plan_cost

On Mon, Dec 11, 2017 at 3:02 AM, David Rowley wrote: > On 9 December 2017 at 06:05, Robert Haas wrote: >> On Thu, Dec 7, 2017 at 3:14 AM, David Rowley >> wrote: >>> The attached is my attempt at putting this right. >> >> I don't feel entirely right about the way this seems to treat >> inheritanc

  1   2   >