Re: [HACKERS] Reviewing freeze map code

On Sat, Jun 4, 2016 at 12:59 AM, Robert Haas wrote: > On Fri, Jun 3, 2016 at 11:21 AM, Masahiko Sawada > wrote: >>> Can you submit that part as a separate patch? >> >> Attached. > > Thanks, committed. > I'm address the review comment of 7087166

Re: [HACKERS] Reviewing freeze map code

On Sat, Jun 4, 2016 at 12:41 PM, Robert Haas wrote: > On Fri, Jun 3, 2016 at 10:25 PM, Masahiko Sawada > wrote: + charnew_vmbuf[BLCKSZ]; + char *new_cur = new_vmbuf; +

Re: [HACKERS] [BUGS] BUG #14155: bloom index error with unlogged table

Jeff Janes writes: > One thing from the commit-message: > "On-disk, we can still store it in words, so as to not break on-disk > compatibility with beta1." > Hasn't that ship already sailed? No. > Or is the concern about intra-version pg_upgrade rather than direct >

Re: [HACKERS] IPv6 link-local addresses and init data type

Robert Haas writes: > Yeah, but what if somebody doesn't want to store scopes? [ shrug... ] We can invent a "strip_scope()" sort of function, analogous to the weight-stripping function for tsvectors, or several other examples. That's a really lame excuse for not being

Re: [HACKERS] IPv6 link-local addresses and init data type

On Fri, Jun 3, 2016 at 5:02 PM, Tom Lane wrote: > Markus Wanner writes: >> That leaves me wondering if it's really worth extending INET, though. >> TEXT would be just fine to store a textual scope id. And it makes it >> utterly clear that there's no magic

Re: [HACKERS] Reviewing freeze map code

On Fri, Jun 3, 2016 at 10:25 PM, Masahiko Sawada wrote: >>> + charnew_vmbuf[BLCKSZ]; >>> + char *new_cur = new_vmbuf; >>> + boolempty = true; >>> + bool

Re: [HACKERS] [BUGS] BUG #14155: bloom index error with unlogged table

On Thu, Jun 2, 2016 at 9:03 PM, Tom Lane wrote: > I wrote: >> Jeff Janes writes: >>> My biggest gripe with it at the moment is that the signature size should be >>> expressed in bits, and then internally rounded up to a multiple of 16, >>> rather than

Re: [HACKERS] [sqlsmith] Failed assertions on parallel worker shutdown

On Thu, May 26, 2016 at 5:57 AM, Amit Kapila wrote: > On Tue, May 24, 2016 at 6:36 PM, Andreas Seltenreich > wrote: >> >> >> Each of the sent plans was collected when a worker dumped core due to >> the failed assertion. More core dumps than plans

Re: [HACKERS] XTM & parallel search

On Fri, Jun 3, 2016 at 6:49 PM, Konstantin Knizhnik < k.knizh...@postgrespro.ru> wrote: > > > On 03.06.2016 16:05, Amit Kapila wrote: > > On Fri, Jun 3, 2016 at 1:34 AM, Konstantin Knizhnik < > k.knizh...@postgrespro.ru> wrote: > >> We have to add three more functions

Re: [HACKERS] HashAggregate row estimate = 200

On 4 June 2016 at 14:10, Christophe Pettus wrote: > Something I've noticed frequently is that HashAggregate will, especially if > the children are Append with one of the nodes a non-seqscan, estimate 200 > rows rather than a calculated vlaue. Where is that value coming from?

Re: [HACKERS] Reviewing freeze map code

On Sat, May 7, 2016 at 5:42 AM, Robert Haas wrote: > On Thu, May 5, 2016 at 2:20 PM, Andres Freund wrote: >> On 2016-05-02 14:48:18 -0700, Andres Freund wrote: >>> 7087166 pg_upgrade: Convert old visibility map format to new format. >> >> +const char *

Re: [HACKERS] Prepared statements and generic plans

On Fri, Jun 3, 2016 at 08:27:38AM -0400, David G. Johnston wrote: > ​This goes back to Bruce's motivation but as long as it goes into the > internals > section I have no problem adding material that someone felt was worth their OK, updated version attached. I added "potential" to the first

[HACKERS] HashAggregate row estimate = 200

Something I've noticed frequently is that HashAggregate will, especially if the children are Append with one of the nodes a non-seqscan, estimate 200 rows rather than a calculated vlaue. Where is that value coming from? The statistics target, a hardwired constant, or something else? -- --

Re: [HACKERS] Perf Benchmarking and regression.

On 2016-06-03 20:41:33 -0400, Noah Misch wrote: > Disabling just backend_flush_after by default works for me, so let's do that. > Though I would not elect, on behalf of PostgreSQL, the risk of enabling > {bgwriter,checkpoint,wal_writer}_flush_after by default, a reasonable person > may choose to

Re: [HACKERS] Perf Benchmarking and regression.

On Fri, Jun 03, 2016 at 03:17:06PM -0400, Robert Haas wrote: > On Fri, Jun 3, 2016 at 2:20 PM, Andres Freund wrote: > >> > I'm inclined to give up and disable backend_flush_after (not the rest), > >> > because it's new and by far the "riskiest". But I do think it's a > >> >

Re: [HACKERS] Parallel safety tagging of extension functions

Hi, Here is the patch split into many small patches as you suggested. The current patches are based on top of the patch which fixes the signatures for gin and gist functions. These patches only touch functions which never should be called directly, so they are fine to skip. I decided to

Re: [HACKERS] Number of parentheses in check constraints affected by operator_precedence_warning

Jean-Pierre Pelletier writes: > We noticed on PostgreSQL 9.5.3 that the number of parentheses in check > constraints expressions > vary depending on the setting of operator_precedence_warning. Hmm, yeah, another place that needs to look through AEXPR_PAREN nodes :-(.

[HACKERS] Number of parentheses in check constraints affected by operator_precedence_warning

Hi, We noticed on PostgreSQL 9.5.3 that the number of parentheses in check constraints expressions vary depending on the setting of operator_precedence_warning. -- The following reproduces this issue which we first saw by restoring into 9.5.3 a 9.4.8 dump on two servers which had different

Re: [HACKERS] [GENERAL] Permission Denied Error on pg_xlog/RECOVERYXLOG file

On 6/3/16 4:13 PM, Robert Haas wrote: > On Fri, Jun 3, 2016 at 2:12 PM, Andres Freund wrote: >> On 2016-06-03 14:00:00 -0400, Robert Haas wrote: >>> On Fri, May 27, 2016 at 8:44 PM, Andres Freund wrote: I'm not convinced of that. Hiding unexpected

Re: [HACKERS] PostmasterPid not marked with PGDLLIMPORT

On Sat, Jun 4, 2016 at 2:56 AM, Robert Haas wrote: > On Wed, Jun 1, 2016 at 7:39 PM, Michael Paquier > wrote: >>> In short, I'd vote for putting this change in HEAD, but I see no need to >>> back-patch. >> >> OK, fine for me. > > Done. Thanks

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Fri, May 27, 2016 at 10:35 AM, Kevin Grittner wrote: > On Tue, May 24, 2016 at 4:10 PM, Robert Haas wrote: >> [ANALYZE of index with expression may fail to update statistics >> if ANALYZE runs longer than old_snapshot_threshold] >> If we can get

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Fri, May 27, 2016 at 10:18 AM, Kevin Grittner wrote: > On Fri, May 27, 2016 at 9:58 AM, Kevin Grittner wrote: >> On Tue, May 24, 2016 at 4:56 PM, Andres Freund wrote: > >>> If an old session with >= repeatable read accesses a

Re: [HACKERS] [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan)

On Wed, Jun 1, 2016 at 9:35 PM, Noah Misch wrote: > [Action required within 72 hours. This is a generic notification.] > > The above-described topic is currently a PostgreSQL 9.6 open item. Robert, > since you committed the patch believed to have created it, you own this open

Re: [HACKERS] IPv6 link-local addresses and init data type

Markus Wanner writes: > That leaves me wondering if it's really worth extending INET, though. > TEXT would be just fine to store a textual scope id. And it makes it > utterly clear that there's no magic involved. True, but it would force users to disassemble and reassemble the

Re: [HACKERS] Changed SRF in targetlist handling

"David G. Johnston" writes: > On Friday, June 3, 2016, Tom Lane > wrote: >> Merlin Moncure writes: >>> another interesting case today is: >>> create sequence s; >>> select

Re: [HACKERS] [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan)

On Thu, May 12, 2016 at 2:07 PM, Tom Lane wrote: >> Err, wow. That makes my head hurt. Can you explain why this case >> only arises for appendrel children, and not for plain rels? > > Well, plain rels only output Vars ;-) Hmm. Dilip's example in

Re: [HACKERS] Perf Benchmarking and regression.

On 2016-06-03 15:17:06 -0400, Robert Haas wrote: > On Fri, Jun 3, 2016 at 2:20 PM, Andres Freund wrote: > >> I've always heard that guideline as "roughly 1/4, but not more than > >> about 8GB" - and the number of people with more than 32GB of RAM is > >> going to just keep

Re: [HACKERS] [GENERAL] Permission Denied Error on pg_xlog/RECOVERYXLOG file

On Fri, Jun 3, 2016 at 2:12 PM, Andres Freund wrote: > On 2016-06-03 14:00:00 -0400, Robert Haas wrote: >> On Fri, May 27, 2016 at 8:44 PM, Andres Freund wrote: >> > I'm not convinced of that. Hiding unexpected issues for longer, just to >> > continue

[HACKERS] Changed SRF in targetlist handling

On Friday, June 3, 2016, Tom Lane > wrote: > Merlin Moncure writes: > > On Wed, May 25, 2016 at 3:55 PM, Tom Lane wrote: > >> Andres Freund writes: > >>> If we go

Re: [HACKERS] Changed SRF in targetlist handling

Merlin Moncure writes: > On Wed, May 25, 2016 at 3:55 PM, Tom Lane wrote: >> Andres Freund writes: >>> If we go with rewriting this into LATERAL, I'd vote for 2.5 (trailed by >>> option 1), that'd keep most of the functionality, and

Re: [HACKERS] Negators for operators

Robert Haas writes: > On Fri, Jun 3, 2016 at 3:02 PM, David Fetter wrote: >> While constructing a somewhat hairy query with HAVING in it, I noticed >> that a lot of operators don't have negators, which would have been >> convenient for the class of

Re: [HACKERS] Negators for operators

On Fri, Jun 3, 2016 at 3:02 PM, David Fetter wrote: > While constructing a somewhat hairy query with HAVING in it, I noticed > that a lot of operators don't have negators, which would have been > convenient for the class of queries I was constructing. Further > investigation

Re: [HACKERS] Perf Benchmarking and regression.

On Fri, Jun 3, 2016 at 2:20 PM, Andres Freund wrote: >> I've always heard that guideline as "roughly 1/4, but not more than >> about 8GB" - and the number of people with more than 32GB of RAM is >> going to just keep going up. > > I think that upper limit is wrong. But even

Re: [HACKERS] Change in order of criteria - reg

On Wed, Jun 1, 2016 at 12:07 AM, sri harsha wrote: > > Hi, > > In PostgreSQL , does the order in which the criteria is given matter > ?? For example > > Query 1 : Select * from TABLE where a > 5 and b < 10; > > Query 2 : Select * from TABLE where b <10 and a > 5; > >

[HACKERS] Negators for operators

Folks, While constructing a somewhat hairy query with HAVING in it, I noticed that a lot of operators don't have negators, which would have been convenient for the class of queries I was constructing. Further investigation showed that while 380 of the built-in operators had negators, 395 do not.

Re: [HACKERS] IPv6 link-local addresses and init data type

On 06/03/2016 06:55 PM, Tom Lane wrote: > More importantly, > on what basis do you conclude that the inet type will only be asked to > store link-local addresses that are currently valid on the local machine? > It is not very hard to think of applications where that wouldn't be the > case. That's

Re: [HACKERS] PostmasterPid not marked with PGDLLIMPORT

On Fri, Jun 3, 2016 at 1:55 PM, Robert Haas wrote: > On Wed, Jun 1, 2016 at 5:59 PM, David G. Johnston > wrote: > > Maybe I don't understand PGDLLEXPORT... > > We're talking about PGDLLIMPORT. > ​Typo, was thinking "we export this for others

Re: [HACKERS] [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan)

On Sat, May 7, 2016 at 9:07 AM, Amit Kapila wrote: > From the above output it is clear that parallel restricted function is > pushed down below gather node. I found that though we have have care fully > avoided to push pathtarget below GatherPath in

Re: [HACKERS] Changed SRF in targetlist handling

On Wed, May 25, 2016 at 3:55 PM, Tom Lane wrote: > Andres Freund writes: >> On 2016-05-25 15:20:03 -0400, Tom Lane wrote: >>> We could certainly make a variant behavior in nodeFunctionscan.c that >>> emulates that, if we feel that being exactly

Re: [HACKERS] Perf Benchmarking and regression.

On 2016-06-03 13:47:58 -0400, Robert Haas wrote: > On Fri, Jun 3, 2016 at 1:43 PM, Andres Freund wrote: > >> I really don't get it. There's nothing in any set of guidelines for > >> setting shared_buffers that I've ever seen which would cause people to > >> avoid this

Re: [HACKERS] [GENERAL] Permission Denied Error on pg_xlog/RECOVERYXLOG file

On 2016-06-03 14:00:00 -0400, Robert Haas wrote: > On Fri, May 27, 2016 at 8:44 PM, Andres Freund wrote: > > I'm not convinced of that. Hiding unexpected issues for longer, just to > > continue kind-of-operating, can make the impact of problems a lot worse, > > and it makes

Re: [HACKERS] Change in order of criteria - reg

On Wed, Jun 1, 2016 at 5:22 AM, Amit Langote wrote: > On 2016/06/01 13:07, sri harsha wrote: >> Hi, >> >> In PostgreSQL , does the order in which the criteria is given matter ?? >> For example >> >> Query 1 : Select * from TABLE where a > 5 and b < 10; >> >>

Re: [HACKERS] [GENERAL] Permission Denied Error on pg_xlog/RECOVERYXLOG file

On Fri, May 27, 2016 at 8:44 PM, Andres Freund wrote: > I'm not convinced of that. Hiding unexpected issues for longer, just to > continue kind-of-operating, can make the impact of problems a lot worse, > and it makes it very hard to actually learn about the issues. So if we

Re: [HACKERS] PostmasterPid not marked with PGDLLIMPORT

On Wed, Jun 1, 2016 at 7:39 PM, Michael Paquier wrote: >> In short, I'd vote for putting this change in HEAD, but I see no need to >> back-patch. > > OK, fine for me. Done. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [HACKERS] PostmasterPid not marked with PGDLLIMPORT

On Wed, Jun 1, 2016 at 5:59 PM, David G. Johnston wrote: > Maybe I don't understand PGDLLEXPORT... We're talking about PGDLLIMPORT. > The PostgreSQL function/feature in question is already in place and can be > accessed by someone using Linux or other unix-like

Re: [HACKERS] Perf Benchmarking and regression.

On Fri, Jun 3, 2016 at 1:43 PM, Andres Freund wrote: >> I really don't get it. There's nothing in any set of guidelines for >> setting shared_buffers that I've ever seen which would cause people to >> avoid this scenario. > > The "roughly 1/4" of memory guideline already

Re: [HACKERS] Perf Benchmarking and regression.

On 2016-06-03 13:42:09 -0400, Tom Lane wrote: > Robert Haas writes: > > On Fri, Jun 3, 2016 at 12:39 PM, Andres Freund wrote: > >> Note that other operating systems like windows and freebsd *alreaddy* > >> write back much more aggressively (independent

Re: [HACKERS] array of domain types

On 6/3/16 11:50 AM, Konstantin Knizhnik wrote: Originally I was mostly interested in domains as kind of typedefs: convenient way to assign type to some particular kind of columns, for example object reference used in ORM. There are two main goals of using domain here: 1. Be able to easily change

Re: [HACKERS] Perf Benchmarking and regression.

On 2016-06-03 13:33:31 -0400, Robert Haas wrote: > On Fri, Jun 3, 2016 at 12:39 PM, Andres Freund wrote: > > On 2016-06-03 12:31:58 -0400, Robert Haas wrote: > >> Now, what varies IME is how much total RAM there is in the system and > >> how frequently they write that data, as

Re: [HACKERS] Perf Benchmarking and regression.

Robert Haas writes: > On Fri, Jun 3, 2016 at 12:39 PM, Andres Freund wrote: >> Note that other operating systems like windows and freebsd *alreaddy* >> write back much more aggressively (independent of this change). I seem >> to recall you yourself

Re: [HACKERS] Tracking wait event for latches

On Thu, Jun 2, 2016 at 1:34 AM, Michael Paquier wrote: > This patch is shaped this way intentionally based on the feedback I > received at PGCon (Robert and others). We could provide a routine that > extensions call in _PG_init to register a new latch event name in >

Re: [HACKERS] Perf Benchmarking and regression.

On Fri, Jun 3, 2016 at 12:39 PM, Andres Freund wrote: > On 2016-06-03 12:31:58 -0400, Robert Haas wrote: >> Now, what varies IME is how much total RAM there is in the system and >> how frequently they write that data, as opposed to reading it. If >> they are on a tightly

Re: [HACKERS] [DOC][PATCH]bloom index options limits

Nikolay Shaplov writes: > Hi! I've changed limits of the length option in the "Introduction" section. > They should be 1 ≤ colN ≤ 2048 instead of 1 < colN < 2048 (I've talk with > the > author about it) I rewrote that text this morning, so this patch won't apply

Re: [HACKERS] IPv6 link-local addresses and init data type

Markus Wanner writes: > Considering that Postgres is not unlikely to write INET types to > permanent storage, its values should better survive a reboot. And while > I have some doubts about persistence of interface names, those clearly > have a higher chance of surviving a

Re: [HACKERS] array of domain types

On 03.06.2016 02:02, Rod Taylor wrote: On Thu, Jun 2, 2016 at 10:42 AM, Konstantin Knizhnik > wrote: On 02.06.2016 17:22, Tom Lane wrote: konstantin knizhnik

Re: [HACKERS] Perf Benchmarking and regression.

On 2016-06-03 12:31:58 -0400, Robert Haas wrote: > Now, what varies IME is how much total RAM there is in the system and > how frequently they write that data, as opposed to reading it. If > they are on a tightly RAM-constrained system, then this situation > won't arise because they won't be

[HACKERS] [DOC][PATCH]bloom index options limits

Hi! I've changed limits of the length option in the "Introduction" section. They should be 1 ≤ colN ≤ 2048 instead of 1 < colN < 2048 (I've talk with the author about it) I've also added minimal maximum and default values for description of options in the "Parameters" section, because I think

Re: [HACKERS] Problem with dumping bloom extension

Michael, * Michael Paquier (michael.paqu...@gmail.com) wrote: > On Fri, Jun 3, 2016 at 8:57 PM, Thom Brown wrote: > > If a database with the bloom extension installed is dumped and restored, > > there's an error with the access method creation: > > > > createdb bloomtest > > psql

Re: [HACKERS] Perf Benchmarking and regression.

On Fri, Jun 3, 2016 at 2:09 AM, Andres Freund wrote: > On 2016-06-03 01:57:33 -0400, Noah Misch wrote: >> > Which means that transactional workloads that are bigger than the OS >> > memory, or which have a non-uniform distribution leading to some >> > locality, are likely to

Re: [HACKERS] Perf Benchmarking and regression.

On 2016-06-03 09:24:28 -0700, Andres Freund wrote: > This unstable performance issue, with the minute-long stalls, is the > worst and most frequent production problem people hit with postgres in > my experience, besides issues with autovacuum. Ignoring that is just > hurting our users. Oh, and a

Re: [HACKERS] Perf Benchmarking and regression.

On 2016-06-03 10:48:18 -0400, Noah Misch wrote: > On Thu, Jun 02, 2016 at 11:09:22PM -0700, Andres Freund wrote: > > > Today's defaults for *_flush_after greatly smooth and accelerate > > > performance > > > for one class of plausible workloads while greatly slowing a different > > > class > > >

Re: [HACKERS] IPv6 link-local addresses and init data type

On 06/03/2016 12:14 AM, Tom Lane wrote: > Markus Wanner writes: >> I'm even wondering if 'fe80::1%1'::inet = 'fe80::1%2'::inet shouldn't >> simply yield true. After all, it's the same (non-global) address. > > Surely not? If the zone_ids didn't mean anything, why would the

Re: [HACKERS] Reviewing freeze map code

On Fri, Jun 3, 2016 at 11:21 AM, Masahiko Sawada wrote: >> Can you submit that part as a separate patch? > > Attached. Thanks, committed. >>> I'm address the review comment of 7087166 commit, and will post the patch. >> >> When? > > On Saturday. Great. Will that address

Re: [HACKERS] Perf Benchmarking and regression.

Hello Noah, The usual PostgreSQL handling of a deeply workload-dependent performance feature is to disable it by default. That's what I'm inclined to do here, for every GUC the feature added. Sophisticated users will nonetheless fully exploit this valuable mechanism in 9.6. I don't think

Re: [HACKERS] Reviewing freeze map code

On Sat, Jun 4, 2016 at 12:08 AM, Robert Haas wrote: > On Fri, Jun 3, 2016 at 10:49 AM, Masahiko Sawada > wrote: >> That patch also incorporates the following review comment. >> We can push at least this fix. > > Can you submit that part as a

Re: [HACKERS] Reviewing freeze map code

On Fri, Jun 3, 2016 at 10:49 AM, Masahiko Sawada wrote: > That patch also incorporates the following review comment. > We can push at least this fix. Can you submit that part as a separate patch? > I'm address the review comment of 7087166 commit, and will post the patch.

Re: [HACKERS] Reviewing freeze map code

On Fri, Jun 3, 2016 at 11:03 PM, Robert Haas wrote: > On Thu, Jun 2, 2016 at 11:24 AM, Masahiko Sawada > wrote: >> Attached patch optimises skipping pages logic so that blkno can jump to >> next_unskippable_block directly while counting the number

Re: [HACKERS] Perf Benchmarking and regression.

On Thu, Jun 02, 2016 at 11:09:22PM -0700, Andres Freund wrote: > On 2016-06-03 01:57:33 -0400, Noah Misch wrote: > > > Which means that transactional workloads that are bigger than the OS > > > memory, or which have a non-uniform distribution leading to some > > > locality, are likely to be

Re: [HACKERS] chkpass_in should not be volatile

On Fri, Jun 3, 2016 at 10:41 AM, Thom Brown wrote: > On 3 June 2016 at 15:26, David G. Johnston > wrote: > >> On Fri, Jun 3, 2016 at 9:56 AM, Tom Lane wrote: >> >>> Thom Brown writes: >>> > ...or at least

Re: [HACKERS] chkpass_in should not be volatile

On 3 June 2016 at 15:26, David G. Johnston wrote: > On Fri, Jun 3, 2016 at 9:56 AM, Tom Lane wrote: > >> Thom Brown writes: >> > ...or at least according to the warning message: >> > postgres=# CREATE EXTENSION chkpass ; >> >

Re: [HACKERS] [BUGS] BUG #14155: bloom index error with unlogged table

Michael Paquier writes: > Actually, the docs could be more polished. I think the docs could stand to be rewritten from scratch ;-). But upthread there was an offer to work on them if we made the code behavior saner. I've done the latter part, I don't want to do the

[HACKERS] Re: pg9.6 segfault using simple query (related to use fk for join estimates)

On Wed, Jun 01, 2016 at 09:29:54PM -0400, Noah Misch wrote: > On Sun, May 29, 2016 at 01:36:01AM -0400, Noah Misch wrote: > > On Fri, May 06, 2016 at 03:06:01PM -0400, Robert Haas wrote: > > > On Thu, May 5, 2016 at 10:48 AM, David Rowley > > > wrote: > > > > On 5

Re: [HACKERS] chkpass_in should not be volatile

On Fri, Jun 3, 2016 at 9:56 AM, Tom Lane wrote: > Thom Brown writes: > > ...or at least according to the warning message: > > postgres=# CREATE EXTENSION chkpass ; > > WARNING: type input function chkpass_in should not be volatile > > See thread here: > > >

Re: [HACKERS] Rename max_parallel_degree?

On 06/02/2016 09:33 PM, Peter Eisentraut wrote: > On 6/3/16 12:21 AM, Petr Jelinek wrote: >> On 01/06/16 17:55, David G. Johnston wrote: >>> On Wed, Jun 1, 2016 at 11:45 AM, Petr Jelinek >> >wrote: >>> >>> That GUC also controls worker

Re: [HACKERS] Reviewing freeze map code

On Wed, Jun 1, 2016 at 3:50 AM, Masahiko Sawada wrote: > Attached patch fixes only above comments, other are being addressed now. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing

Re: [HACKERS] Reviewing freeze map code

On Thu, Jun 2, 2016 at 11:24 AM, Masahiko Sawada wrote: > Attached patch optimises skipping pages logic so that blkno can jump to > next_unskippable_block directly while counting the number of all_visible > and all_frozen pages. So we can avoid double checking visibility

Re: [HACKERS] chkpass_in should not be volatile

Thom Brown writes: > ...or at least according to the warning message: > postgres=# CREATE EXTENSION chkpass ; > WARNING: type input function chkpass_in should not be volatile See thread here:

Re: [HACKERS] Problem with dumping bloom extension

On Fri, Jun 3, 2016 at 8:57 PM, Thom Brown wrote: > If a database with the bloom extension installed is dumped and restored, > there's an error with the access method creation: > > createdb bloomtest > psql -c 'CREATE EXTENSION bloom;' bloomtest > pg_dump -d bloomtest >

Re: [HACKERS] Parallel pg_dump's error reporting doesn't work worth squat

Kyotaro HORIGUCHI writes: > For sure, any of the "dangers" of TerminateThread don't matter > for this case. I think that this one: >> If the target thread is allocating memory from the heap, the heap >> lock will not be released. is potentially a hazard, which

Re: [HACKERS] Rename max_parallel_degree?

Robert Haas writes: > I think we should just go with max_parallel_workers for a limit on > total parallel workers within max_work_processes, and > max_parallel_workers_per_gather for a per-Gather limit. It's slightly > annoying that we may end up renaming the latter GUC,

Re: [HACKERS] XTM & parallel search

On 03.06.2016 16:05, Amit Kapila wrote: On Fri, Jun 3, 2016 at 1:34 AM, Konstantin Knizhnik > wrote: We have to add three more functions to eXtensible Transaction Manager API (XTM): /* * Calculate

Re: [HACKERS] XTM & parallel search

On Fri, Jun 3, 2016 at 1:34 AM, Konstantin Knizhnik < k.knizh...@postgrespro.ru> wrote: > We have to add three more functions to eXtensible Transaction Manager API > (XTM): > > /* > * Calculate transaction state size. This method is invoked by > EstimateTransactionStateSpace to copy

Re: [HACKERS] Rename max_parallel_degree?

On Fri, Jun 3, 2016 at 8:30 AM, David G. Johnston wrote: > How big is the hazard of future-naming this and documenting the present > limitation? Is the casual user reading explains even going to be aware of > that particular implementation detail? Well, see, the nice

Re: [HACKERS] Rename max_parallel_degree?

On Fri, Jun 3, 2016 at 8:20 AM, Robert Haas wrote: > On Thu, Jun 2, 2016 at 4:35 PM, Josh berkus wrote: > > I was assuming that we would have *both* per-operation and per-statement > > limits. I can see reasons for having both, I can see why power

Re: [HACKERS] Prepared statements and generic plans

On Fri, Jun 3, 2016 at 3:17 AM, Albe Laurenz wrote: > > > I'd maybe go with something like this: > > > > All executions of a prepared statement having zero parameters will use > the same plan so the planning > > time taken during the first execution will be spread across

Re: [HACKERS] Rename max_parallel_degree?

On Thu, Jun 2, 2016 at 4:35 PM, Josh berkus wrote: > I was assuming that we would have *both* per-operation and per-statement > limits. I can see reasons for having both, I can see why power users > would want both, but it's going to be overwhelming to casual users. I don't

[HACKERS] Problem with dumping bloom extension

Hi, If a database with the bloom extension installed is dumped and restored, there's an error with the access method creation: createdb bloomtest psql -c 'CREATE EXTENSION bloom;' bloomtest pg_dump -d bloomtest > ~/tmp/bloom.sql createdb bloomtest2 psql -d bloomtest2 -f ~/tmp/bloom.sql The

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

2016-05-24 5:01 GMT+03:00 Craig Ringer : > > On 24 May 2016 at 00:00, Michael Paquier wrote: >> >> On Mon, May 23, 2016 at 8:50 AM, Andres Freund wrote: > > >> >> > yay^2. >> >> I'll follow this mood. Yeha. > > > > BTW, I've

[HACKERS] chkpass_in should not be volatile

...or at least according to the warning message: postgres=# CREATE EXTENSION chkpass ; WARNING: type input function chkpass_in should not be volatile Thom

[HACKERS] hstore: add hstore_length function

Hi there- I've attached a small patch exposing HS_COUNT to the user as "hstore_length(hstore)". Documentation, upgrade sql files, and a few tests are also included. Almost every hstore function calls HS_COUNT, but I couldn't determine if there was a reason this exposure didn't already exist.

Re: [HACKERS] Rename synchronous_standby_names?

On 01/06/16 02:49, Michael Paquier wrote: > On Wed, Jun 1, 2016 at 3:56 AM, David G. Johnston > wrote: >> On Tue, May 31, 2016 at 2:19 PM, Peter Eisentraut >> wrote: >>> >>> On 5/31/16 1:47 PM, Jaime Casanova wrote: Are we

Re: [HACKERS] Statement timeout

>> I didn't noticed it. Could you give me the message id or URL? >> >> > https://commitfest.postgresql.org/10/634/ > > https://www.postgresql.org/message-id/flat/CAMsr+YFUjJytRyV4J-16bEoiZyH=4nj+sQ7JP9ajwz=b4dm...@mail.gmail.com#CAMsr+YFUjJytRyV4J-16bEoiZyH=4nj+sQ7JP9ajwz=b4dm...@mail.gmail.com

Re: [HACKERS] Parallel pg_dump's error reporting doesn't work worth squat

At Thu, 2 Jun 2016 12:17:11 -0400, Alvaro Herrera wrote in <20160602161711.GA239156@alvherre.pgsql> > Tom Lane wrote: > > Kyotaro HORIGUCHI writes: > > > Apart from the invalid snapshot problem, I looked the patch > > > previously

Re: [HACKERS] Let file_fdw access COPY FROM PROGRAM

On Fri, Jun 3, 2016 at 1:06 AM, Craig Ringer wrote: > On 3 June 2016 at 04:48, Corey Huinker wrote: > >> A while back, there was a push to make COPY gzip-aware. That didn't >> happen, but COPY FROM PROGRAM did, and it scratches the same itch. >> >

Re: [HACKERS] Prepared statements and generic plans

David G. Johnston wrote: > On Thu, Jun 2, 2016 at 9:56 PM, Bruce Momjian wrote: >> In Postgres 9.2 we improved the logic of when generic plans are used by >> EXECUTE. We weren't sure how well it would work, and the docs included >> a vague description on when generic plans are

Re: [HACKERS] regexp_match() returning text

On 5/30/16 1:01 PM, Andrew Gierth wrote: Returning an array containing the values of all capture groups might be more useful (substring returns the value of the first capture group if any, otherwise the matched string). +1. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX

Re: [HACKERS] Rename max_parallel_degree?

Robert Haas wrote: > On Wed, Jun 1, 2016 at 5:29 PM, Tom Lane wrote: > > Robert Haas writes: > >> I've largely given up hope of coming up with an alternative that can > >> attract more than one vote and that is also at least mildly accurate, > >> but

Re: [HACKERS] [BUGS] BUG #14155: bloom index error with unlogged table

On Fri, Jun 3, 2016 at 3:11 PM, Michael Paquier wrote: > On Fri, Jun 3, 2016 at 1:03 PM, Tom Lane wrote: >> I wrote: >>> Jeff Janes writes: My biggest gripe with it at the moment is that the signature size should be

Re: [HACKERS] [BUGS] BUG #14155: bloom index error with unlogged table

On Fri, Jun 3, 2016 at 1:03 PM, Tom Lane wrote: > I wrote: >> Jeff Janes writes: >>> My biggest gripe with it at the moment is that the signature size should be >>> expressed in bits, and then internally rounded up to a multiple of 16, >>> rather than

Re: [HACKERS] Perf Benchmarking and regression.

On 2016-06-03 01:57:33 -0400, Noah Misch wrote: > > Which means that transactional workloads that are bigger than the OS > > memory, or which have a non-uniform distribution leading to some > > locality, are likely to be faster. In practice those are *hugely* more > > likely than the uniform

  1   2   >