Re: [HACKERS] can we add SKIP LOCKED to UPDATE?

On 10.11.2015 07:23, Craig Ringer wrote: On 10 November 2015 at 01:38, Jeff Janes wrote: this would be handy in conjunction with LIMIT (which also doesn't exist for UPDATE right now). ... and, in turn, UPDATE ... ORDER BY ..., since LIMIT without ORDER BY is usually

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On Wed, Nov 11, 2015 at 9:42 PM, Heikki Linnakangas wrote: > On 11/11/2015 10:23 AM, Simon Riggs wrote: > >> On 11 November 2015 at 05:37, Thomas Munro > > >> wrote: >> >> Many sites use hot standby servers to spread read-heavy workloads over >>

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On Wed, Nov 11, 2015 at 11:22 AM, Thomas Munro wrote: > On Wed, Nov 11, 2015 at 9:42 PM, Heikki Linnakangas wrote: >> On 11/11/2015 10:23 AM, Simon Riggs wrote: >>> Thanks for working on this issue. >> >> +1. +1. I have seen a lot of interest for

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

> I'm thinking the client should get some kind of a token back from the commit, and it could use the token on the standby, to wait for that commit to be applied. The token could be just the XID, or the LSN of the commit record. Or the application could generate the token and pass it to the server

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On 11/11/2015 10:23 AM, Simon Riggs wrote: On 11 November 2015 at 05:37, Thomas Munro wrote: Many sites use hot standby servers to spread read-heavy workloads over more hardware, or at least would like to. This works well today if your application can tolerate

[HACKERS] proposal: numeric scale functions

Hi, Dealing with "numeric"s right now in cases where it's really important that the scale is correct is quite painful. For example, if I want to accept a EUR amount as an input, I often want to reject values such as '21.413', but I'd be fine with e.g. '21.41'. My suggestion is to add

Re: [HACKERS] Some questions about the array.

On Friday 06 November 2015 12:55:44 you wrote: > Omitted bounds are common in other languages and would be handy. I > don't think they'd cause any issues with multi-dimensional arrays or > variable start-pos arrays. And yet, what about my patch? Discussions about ~ and{:} it seems optional.

[HACKERS] Python 3 compatibility fun

According to https://bugzilla.redhat.com/show_bug.cgi?id=1280404 we're failing to build against Python 3.5 because the python guys have randomly changed some error message texts, again. In the short run the answer must be to add some more variant expected-files, but I wonder if we should be

Re: [HACKERS] Parallel Seq Scan

2015-11-11 19:03 GMT+01:00 Thom Brown : > On 11 November 2015 at 17:59, Pavel Stehule > wrote: > > Hi > > > > I have a first query > > > > I looked on EXPLAIN ANALYZE output and the numbers of filtered rows are > > differen > > > > postgres=# set

Re: [HACKERS] [COMMITTERS] pgsql: Translation updates

On 11/10/15 12:03 PM, Alvaro Herrera wrote: > Peter Eisentraut wrote: >> Translation updates >> >> Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git >> Source-Git-Hash: cd263526676705b4a8a3a708c9842461c4a2bcc3 > > Hi Peter, > > Would you please document this process? It's

Re: [HACKERS] Patch to install config/missing

Peter Eisentraut writes: > On 11/2/15 4:07 PM, Tom Lane wrote: >> I wonder how much we need that script at all though. If, say, configure >> doesn't find bison, what's so wrong with just defining BISON=bison and >> letting the usual shell "bison: command not found" error leak

Re: [HACKERS] Parallel Seq Scan

Hi I have a first query I looked on EXPLAIN ANALYZE output and the numbers of filtered rows are differen postgres=# set max_parallel_degree to 4; SET Time: 0.717 ms postgres=# EXPLAIN ANALYZE select count(*) from xxx where a % 10 = 0;

Re: [HACKERS] Parallel Seq Scan

On 11 November 2015 at 17:59, Pavel Stehule wrote: > Hi > > I have a first query > > I looked on EXPLAIN ANALYZE output and the numbers of filtered rows are > differen > > postgres=# set max_parallel_degree to 4; > SET > Time: 0.717 ms > postgres=# EXPLAIN ANALYZE select

Re: [HACKERS] Patch to install config/missing

On 11/2/15 4:07 PM, Tom Lane wrote: > I wonder how much we need that script at all though. If, say, configure > doesn't find bison, what's so wrong with just defining BISON=bison and > letting the usual shell "bison: command not found" error leak through? I agree. Something like the attached

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On Sun, Nov 8, 2015 at 11:13 PM, Etsuro Fujita wrote: > To test this change, I think we should update the postgres_fdw patch so as > to add the RecheckForeignScan. > > Having said that, as I said previously, I don't see much value in adding the > callback routine, to

Re: [HACKERS] Python 3 compatibility fun

On 11/11/15 12:08 PM, Tom Lane wrote: > we're failing to build against Python 3.5 because the python guys > have randomly changed some error message texts, again. This has already been fixed in the 9.5. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] Parallel Seq Scan

On Wed, Nov 11, 2015 at 11:53 PM, Robert Haas wrote: > For those following along at home, here's a demo: > > rhaas=# \timing > Timing is on. > rhaas=# select * from pgbench_accounts where filler like '%a%'; > aid | bid | abalance | filler > -+-+--+

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

I wrote: > When I checked the behavior of 5d1ff6bd559ea8df, I must have only > tried it for unshared catalogs. Those are set up by > RelationCacheInitializePhase3, which is post-authentication, so the > message comes out and causes regression test failures as expected. > This is kind of annoying

Re: [HACKERS] Parallel Seq Scan

On Mon, Nov 9, 2015 at 11:15 AM, Amit Kapila wrote: > Okay, I have updated the patch to make seq scan node parallel aware. > To make that happen we need to have parallel_aware flag both in Plan > as well as Path, so that we can pass that information from Path to Plan. > I

Re: [HACKERS] Parallel Seq Scan

On 11 November 2015 at 14:53, Robert Haas wrote: > On Mon, Nov 9, 2015 at 11:15 AM, Amit Kapila wrote: >> Okay, I have updated the patch to make seq scan node parallel aware. >> To make that happen we need to have parallel_aware flag both in Plan

Re: [HACKERS] Parallel Seq Scan

2015-11-11 16:18 GMT+01:00 Thom Brown : > On 11 November 2015 at 14:53, Robert Haas wrote: > > On Mon, Nov 9, 2015 at 11:15 AM, Amit Kapila > wrote: > >> Okay, I have updated the patch to make seq scan node parallel aware. > >> To

Re: [HACKERS] pageinspect patch, for showing tuple data

В письме от 28 октября 2015 16:57:36 пользователь Michael Paquier написал: > On Sat, Oct 17, 2015 at 1:48 AM, Michael Paquier wrote: > > On Sat, Oct 17, 2015 at 5:15 AM, Nikolay Shaplov wrote: > >> Or it's ready to commit, and just not marked this way? > > > > No, I don't think we have reached

Re: [HACKERS] Some questions about the array.

On Mon, Nov 9, 2015 at 8:23 PM, Pavel Stehule wrote: > 2015-11-09 17:55 GMT+01:00 Alexander Korotkov : > >> On Mon, Nov 9, 2015 at 4:53 PM, Pavel Stehule >> wrote: >> >>> 2015-11-09 14:44 GMT+01:00 YUriy Zhuravlev

Re: [HACKERS] Some questions about the array.

2015-11-11 12:25 GMT+01:00 YUriy Zhuravlev : > On Friday 06 November 2015 12:55:44 you wrote: > > Omitted bounds are common in other languages and would be handy. I > > don't think they'd cause any issues with multi-dimensional arrays or > > variable start-pos arrays.

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On Wed, Nov 11, 2015 at 3:23 AM, Simon Riggs wrote: > This causes every writer to wait. > > What we want is to isolate the wait only to people performing a write-read > sequence, so I think it should be readers that wait. Let's have that debate > up front before we start

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 11 November 2015 at 06:04, Michael Paquier wrote: >>> I also modified some of the CHECKFLOATVAL() checks which didn't look >>> right to me, unless there's some odd platform-specific behaviour that >>> I'm not aware of, functions like sin and asin should never return

Re: [HACKERS] can we add SKIP LOCKED to UPDATE?

On 11 November 2015 at 16:02, Torsten Zühlsdorff < mailingli...@toco-domains.de> wrote: > From my experience most databases are just tpo small. Their operations > finish before there can be a deadlock. Same for race conditions - most > developer don't know about them, because they never stumbled

Re: [HACKERS] proposal: numeric scale functions

On 11/11/15 5:03 AM, Marko Tiikkaja wrote: > Dealing with "numeric"s right now in cases where it's really important > that the scale is correct is quite painful. For example, if I want to > accept a EUR amount as an input, I often want to reject values such as > '21.413', but I'd be fine with

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On 11/09/2015 10:32 PM, Ildus Kurbangaliev wrote: On Nov 9, 2015, at 7:56 PM, Alvaro Herrera wrote: Ildus Kurbangaliev wrote: Thanks for the review. I've attached a new version of SLRU patch. I've removed add_postfix and fixed EXEC_BACKEND case. Thanks. Please

Re: [HACKERS] proposal: multiple psql option -c

On Tue, Nov 10, 2015 at 2:18 AM, Pavel Stehule wrote: > Hi > > 2015-11-05 22:23 GMT+01:00 Robert Haas : >> >> On Thu, Nov 5, 2015 at 3:53 PM, Catalin Iacob >> wrote: >> > On Thu, Nov 5, 2015 at 5:27 PM, Robert Haas

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On Thu, Nov 12, 2015 at 12:10 AM, Ants Aasma wrote: > On Wed, Nov 11, 2015 at 11:22 AM, Thomas Munro > wrote: > > On Wed, Nov 11, 2015 at 9:42 PM, Heikki Linnakangas > wrote: > >> On 11/11/2015 10:23 AM, Simon Riggs wrote: >

Re: [HACKERS] Per-table log_autovacuum_min_duration is actually documented

On Thu, Nov 12, 2015 at 9:06 AM, Tom Lane wrote: > Michael Paquier writes: >> On Thu, Nov 12, 2015 at 6:27 AM, Alvaro Herrera >> wrote: >>> I think you're remembering this: >>>

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/11/12 2:53, Robert Haas wrote: On Sun, Nov 8, 2015 at 11:13 PM, Etsuro Fujita wrote: To test this change, I think we should update the postgres_fdw patch so as to add the RecheckForeignScan. Having said that, as I said previously, I don't see much value in

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On Wed, Nov 4, 2015 at 6:30 PM, David Rowley wrote: >> Have you thought about *just* having an int64 pg_ltostr()? Are you >> aware of an appreciable overhead from having int32 callers just rely >> on a promotion to int64? > > I'd not thought of that. It would

Re: CustomScan in a larger structure (RE: [HACKERS] CustomScan support on readfuncs.c)

> On Wed, Nov 11, 2015 at 3:29 PM, Andres Freund wrote: > > On 2015-11-11 14:59:33 -0500, Robert Haas wrote: > >> I don't see this as being a particularly good idea. The same issue > >> exists for FDWs, and we're just living with it in that case. > > > > It's absolutely

Re: CustomScan in a larger structure (RE: [HACKERS] CustomScan support on readfuncs.c)

> Robert Haas writes: > > On Wed, Nov 11, 2015 at 3:29 PM, Andres Freund wrote: > >> Just better serialization doesn't actually help all that much. Being > >> able to conveniently access data directly, i.e. as fields in a struct, > >> makes code rather

Re: [HACKERS] [DESIGN] ParallelAppend

I'm now designing the parallel feature of Append... Here is one challenge. How do we determine whether each sub-plan allows execution in the background worker context? The commit f0661c4e8c44c0ec7acd4ea7c82e85b265447398 added 'parallel_aware' flag on Path and Plan structure. It tells us whether

Re: [HACKERS] can we add SKIP LOCKED to UPDATE?

On Wed, Nov 11, 2015 at 6:57 PM, Gavin Flower wrote: > Don't you realize that 400MB is over 4 million of the old 100Kb floppy > disks, and even with the new big 1.44MB 3.5 " disks, you'd need about 280!!! Don't be silly. It's only four thousand 100Kb floppies. --

Re: [HACKERS] Parallel Seq Scan

On 2015/11/12 4:26, Robert Haas wrote: > On Wed, Nov 11, 2015 at 12:59 PM, Pavel Stehule > wrote: >> I have a first query >> >> I looked on EXPLAIN ANALYZE output and the numbers of filtered rows are >> differen > > Hmm, I see I was right about people finding more bugs

Re: [HACKERS] Making tab-complete.c easier to maintain

New version attached, merging recent changes. -- Thomas Munro http://www.enterprisedb.com tab-complete-v8.patch.gz Description: GNU Zip compressed data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] [DESIGN] ParallelAppend

On 2015/11/12 14:09, Kouhei Kaigai wrote: > I'm now designing the parallel feature of Append... > > Here is one challenge. How do we determine whether each sub-plan > allows execution in the background worker context? > > The commit f0661c4e8c44c0ec7acd4ea7c82e85b265447398 added >

Re: [HACKERS] pglogical_output - a general purpose logical decoding output plugin

On 3 November 2015 at 02:58, Jim Nasby wrote: > On 11/2/15 8:36 AM, Craig Ringer wrote: > >> Here's the protocol documentation discussed in the README. It's >> asciidoc at the moment, so it can be formatted into something with >> readable tables. >> > > Is this by

Re: [HACKERS] proposal: multiple psql option -c

On Thu, Nov 12, 2015 at 9:35 AM, David G. Johnston wrote: > On Wed, Nov 11, 2015 at 7:01 AM, Michael Paquier > wrote: >> >> It seems to me that the documentation should specify that when -C is >> used with -1 each individual series of

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

Hello, > > I really don't see why you're fighting on this point. Making this a > > generic feature will require only a few extra lines of code for FDW > > authors. If this were going to cause some great inconvenience for FDW > > authors, then I'd agree it isn't worth it. But I see zero

Re: [HACKERS] pageinspect patch, for showing tuple data

On Thu, Nov 12, 2015 at 9:04 AM, Michael Paquier wrote: > On Thu, Nov 12, 2015 at 12:41 AM, Nikolay Shaplov wrote: >> I still have an opinion that documentation should be more verbose, than your >> version, but I can accept your version. > > I am not sure that's necessary, pageinspect is for

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

> -Original Message- > From: Etsuro Fujita [mailto:fujita.ets...@lab.ntt.co.jp] > Sent: Thursday, November 12, 2015 2:54 PM > To: Robert Haas > Cc: Kaigai Kouhei(海外 浩平); Tom Lane; Kyotaro HORIGUCHI; > pgsql-hackers@postgresql.org; Shigeru Hanada > Subject: Re: [HACKERS] Foreign join

Re: [HACKERS] proposal: multiple psql option -c

2015-11-12 1:35 GMT+01:00 David G. Johnston : > On Wed, Nov 11, 2015 at 7:01 AM, Michael Paquier < > michael.paqu...@gmail.com> wrote: > >> It seems to me that the documentation should specify that when -C is >> used with -1 each individual series of commands is

Re: [HACKERS] Parallel Seq Scan

On 11 November 2015 at 19:51, Thom Brown wrote: > On 11 November 2015 at 19:26, Robert Haas wrote: >> On Wed, Nov 11, 2015 at 12:59 PM, Pavel Stehule >> wrote: >>> I have a first query >>> >>> I looked on EXPLAIN ANALYZE output

Re: [HACKERS] Per-table log_autovacuum_min_duration is actually documented

On Thu, Nov 12, 2015 at 6:27 AM, Alvaro Herrera wrote: > Michael Paquier wrote: > >> I recall that we had some talks about grouping all the relopts into a >> single documentation section, perhaps not having one is at the origin >> of the confusion? > > I think you're

Re: [HACKERS] pageinspect patch, for showing tuple data

On Thu, Nov 12, 2015 at 12:41 AM, Nikolay Shaplov wrote: > В письме от 28 октября 2015 16:57:36 пользователь Michael Paquier написал: >> On Sat, Oct 17, 2015 at 1:48 AM, Michael Paquier wrote: >> > On Sat, Oct 17, 2015 at 5:15 AM, Nikolay Shaplov wrote: >> >> Or it's

Re: [HACKERS] Per-table log_autovacuum_min_duration is actually documented

Michael Paquier writes: > On Thu, Nov 12, 2015 at 6:27 AM, Alvaro Herrera > wrote: >> I think you're remembering this: >> http://www.postgresql.org/message-id/20150402205713.gb22...@eldon.alvh.no-ip.org > Right. Thanks. Do you think we'd

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

On 11/11/2015 11:31 AM, Tom Lane wrote: > After sleeping on it, the best compromise I can think of is to add an > "Assert(false)" after the WARNING report for the shared-catalogs case. > This will make the failure un-missable in any development build, while > not breaking production builds'

Re: [HACKERS] Python 3 compatibility fun

Peter Eisentraut writes: > On 11/11/15 12:08 PM, Tom Lane wrote: >> we're failing to build against Python 3.5 because the python guys >> have randomly changed some error message texts, again. > This has already been fixed in the 9.5. Well, that's nice, but surely it should have

Re: [HACKERS] Patch to install config/missing

Andrew Dunstan writes: > On 11/11/2015 12:34 PM, Tom Lane wrote: >> I was thinking more of removing the "missing" script and associated logic >> entirely, rather than making PGXS a special case. I think we should do >> our best to minimize differences between behaviors in

Re: CustomScan in a larger structure (RE: [HACKERS] CustomScan support on readfuncs.c)

On Mon, Nov 9, 2015 at 10:26 PM, Kouhei Kaigai wrote: > It is a relevant topic of readfuncs support for custom-scan. > > Unlike CustomPath and CustomScanState, we don't allow custom-scan > provider to define own and larger structure that embeds CustomScan > at head of the

Re: [HACKERS] [COMMITTERS] pgsql: Translation updates

Peter Eisentraut wrote: > On 11/10/15 12:03 PM, Alvaro Herrera wrote: > > Peter Eisentraut wrote: > >> Translation updates > >> > >> Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git > >> Source-Git-Hash: cd263526676705b4a8a3a708c9842461c4a2bcc3 > > > > Hi Peter, > > > >

Re: [HACKERS] Parallel Seq Scan

2015-11-11 20:26 GMT+01:00 Robert Haas : > On Wed, Nov 11, 2015 at 12:59 PM, Pavel Stehule > wrote: > > I have a first query > > > > I looked on EXPLAIN ANALYZE output and the numbers of filtered rows are > > differen > > Hmm, I see I was right

Re: [HACKERS] Patch to install config/missing

On 11/11/15 12:34 PM, Tom Lane wrote: > I was thinking more of removing the "missing" script and associated logic > entirely, rather than making PGXS a special case. I think we should do > our best to minimize differences between behaviors in core builds and > PGXS builds, if only because we

Re: [HACKERS] Some questions about the array.

On Wednesday 11 November 2015 17:29:31 you wrote: > In this case the syntax is major issue. Any language should not to have any > possible feature on the world. I am about omitted boundaries. It almost does not change the syntax and with nothing conflicts. Thanks. -- YUriy Zhuravlev Postgres

Re: [HACKERS] Patch to install config/missing

On 11/11/2015 12:34 PM, Tom Lane wrote: Peter Eisentraut writes: On 11/2/15 4:07 PM, Tom Lane wrote: I wonder how much we need that script at all though. If, say, configure doesn't find bison, what's so wrong with just defining BISON=bison and letting the usual shell

Re: [HACKERS] Parallel Seq Scan

On 11 November 2015 at 19:26, Robert Haas wrote: > On Wed, Nov 11, 2015 at 12:59 PM, Pavel Stehule > wrote: >> I have a first query >> >> I looked on EXPLAIN ANALYZE output and the numbers of filtered rows are >> differen > > Hmm, I see I was

Re: [HACKERS] proposal: multiple psql option -c

On Wed, Nov 11, 2015 at 7:01 AM, Michael Paquier wrote: > It seems to me that the documentation should specify that when -C is > used with -1 each individual series of commands is executed within a > transaction block. ​In summary: Default (Not Single +

Re: [HACKERS] can we add SKIP LOCKED to UPDATE?

On 12/11/15 13:52, Greg Stark wrote: On Wed, Nov 11, 2015 at 6:57 PM, Gavin Flower wrote: Don't you realize that 400MB is over 4 million of the old 100Kb floppy disks, and even with the new big 1.44MB 3.5 " disks, you'd need about 280!!! Don't be silly. It's

Re: CustomScan in a larger structure (RE: [HACKERS] CustomScan support on readfuncs.c)

On 2015-11-11 14:59:33 -0500, Robert Haas wrote: > I don't see this as being a particularly good idea. The same issue > exists for FDWs, and we're just living with it in that case. It's absolutely horrible there. I don't see why that's a justification for much. To deal with the lack of

Re: [HACKERS] Per-table log_autovacuum_min_duration is actually documented

Michael Paquier wrote: > I recall that we had some talks about grouping all the relopts into a > single documentation section, perhaps not having one is at the origin > of the confusion? I think you're remembering this:

Re: [HACKERS] Patch to install config/missing

Peter Eisentraut wrote: > On 11/11/15 12:34 PM, Tom Lane wrote: > > I was thinking more of removing the "missing" script and associated logic > > entirely, rather than making PGXS a special case. I think we should do > > our best to minimize differences between behaviors in core builds and > >

Re: [HACKERS] can we add SKIP LOCKED to UPDATE?

On 12/11/15 02:07, Craig Ringer wrote: On 11 November 2015 at 16:02, Torsten Zühlsdorff > wrote: From my experience most databases are just tpo small. Their operations finish before there can be a deadlock. Same for

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On 11/11/15 4:22 AM, Thomas Munro wrote: > My thinking was that the reason for wanting to load balance over a set > of hot standbys is because you have a very read-heavy workload, so it > makes sense to tax the writers and leave the many dominant readers > unburdened, so (3) should be better than

Re: [HACKERS] Parallel Seq Scan

On Wed, Nov 11, 2015 at 12:59 PM, Pavel Stehule wrote: > I have a first query > > I looked on EXPLAIN ANALYZE output and the numbers of filtered rows are > differen Hmm, I see I was right about people finding more bugs once this was committed. That didn't take long.

Re: CustomScan in a larger structure (RE: [HACKERS] CustomScan support on readfuncs.c)

Robert Haas writes: > On Wed, Nov 11, 2015 at 3:29 PM, Andres Freund wrote: >> Just better serialization doesn't actually help all that much. Being >> able to conveniently access data directly, i.e. as fields in a struct, >> makes code rather more

Re: CustomScan in a larger structure (RE: [HACKERS] CustomScan support on readfuncs.c)

On Wed, Nov 11, 2015 at 3:29 PM, Andres Freund wrote: > On 2015-11-11 14:59:33 -0500, Robert Haas wrote: >> I don't see this as being a particularly good idea. The same issue >> exists for FDWs, and we're just living with it in that case. > > It's absolutely horrible there. I

Re: [HACKERS] Per-table log_autovacuum_min_duration is actually documented

Michael Paquier writes: > On Wed, Nov 11, 2015 at 12:07 AM, Tom Lane wrote: >> Should it read "Overrides log_autovacuum_min_duration for autovacuum >> operations on this specific table or toast table"? > The same applied for all the other

Re: [HACKERS] Per-table log_autovacuum_min_duration is actually documented

Tom Lane wrote: > Michael Paquier writes: > > On Wed, Nov 11, 2015 at 12:07 AM, Tom Lane wrote: > >> Should it read "Overrides log_autovacuum_min_duration for autovacuum > >> operations on this specific table or toast table"? > > > The same applied

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On 11 November 2015 at 05:37, Thomas Munro wrote: Many sites use hot standby servers to spread read-heavy workloads over more > hardware, or at least would like to. This works well today if your > application can tolerate some time lag on standbys. The problem is