On Tue, Feb 3, 2015 at 10:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Two reasons this isn't terribly compelling are (1) it's creating a
join in a place where the planner can't possibly see it and optimize
it, and (2) you risk MVCC anomalies because the reg* output routines
would not be using
Surely they should be assignment level, if not implicit. I don't
really see why I should have to write a cast to assign a json
expression result into a jsonb column, in particular.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On Sat, Feb 21, 2015 at 11:08 PM, Andres Freund and...@2ndquadrant.com wrote:
The changes in pg_proc.h are just to demonstrate that using names
instead of oids works.
Fwiw I always thought it was strange how much of our bootstrap was
done in a large static text file. Very little of it is
On Tue, Mar 3, 2015 at 4:57 AM, Stephen Frost sfr...@snowman.net wrote:
* Michael Paquier (michael.paqu...@gmail.com) wrote:
On Mon, Mar 2, 2015 at 6:27 AM, Stephen Frost sfr...@snowman.net wrote:
Please see the latest version of this, attached. I've removed the left
join, re-used the
On Mon, Mar 2, 2015 at 12:15 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
Hmm. I used a b-tree to estimate the effect that the locking would have in
the UPSERT case, for UPSERT into a table with a b-tree index. But you're
right that for the question of whether this is acceptable for the case
On 2015-03-02 16:32:53 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
The easiest way to solve this would teach ruleutils.c to simply always
attach AS clauses for auto-generated columnnames. Won't look too pretty
though. Does somebody have a better idea?
No, it would
On Mon, Mar 2, 2015 at 7:51 PM, Greg Stark st...@mit.edu wrote:
Nobody's allocating anything that big. It's a list of 25,000 pointers
to 472-byte structs. That should add up to about 11MB. Instead the
memory context is a total of 954606152 bytes which is still under a
gigabyte and the database
Andres Freund and...@2ndquadrant.com writes:
CREATE VIEW v_03 AS
SELECT * FROM (SELECT '2' ORDER BY 1) s;
View definition:
SELECT s.?column?
FROM ( SELECT '2'::text
ORDER BY '2'::text) s;
Note the added cast to determine the type of the expression and the
generated column
On 2015-03-02 16:42:35 -0500, Robert Haas wrote:
On Tue, Feb 3, 2015 at 10:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Two reasons this isn't terribly compelling are (1) it's creating a
join in a place where the planner can't possibly see it and optimize
it, and (2) you risk MVCC anomalies
On Mon, Mar 02, 2015 at 04:52:37PM -0500, Robert Haas wrote:
On Mon, Feb 23, 2015 at 3:56 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
David Fetter wrote:
My thinking behind this was that the patch is a bug fix and intended
to be back-patched, so I wanted to mess with as little
On Sat, Feb 28, 2015 at 12:27 AM, Stephen Frost sfr...@snowman.net wrote:
While this generally works, the usual expectation is that functions
that should be superuser-only have a check in the function rather than
depending on the execute privilege. I'm certainly happy to debate the
merits of
On Mon, Feb 23, 2015 at 3:56 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
David Fetter wrote:
My thinking behind this was that the patch is a bug fix and intended
to be back-patched, so I wanted to mess with as little infrastructure
as possible. A new version of libpq seems like a very
On Thu, Feb 19, 2015 at 12:29:18PM +0900, Fujii Masao wrote:
The pg_audit doesn't log BIND parameter values when prepared statement is
used.
Seems this is an oversight of the patch. Or is this intentional?
It's actually intentional - following the model I talked about in my
earlier
Hi,
On 2015-03-02 15:40:27 -0800, Josh Berkus wrote:
! #max_wal_size = 1GB # in logfile segments
Independent of the rest of the changes, the in logfile segments bit
should probably be changed.
Greetings,
Andres Freund
--
Andres Freund
On 03/02/2015 03:43 PM, Andres Freund wrote:
Hi,
On 2015-03-02 15:40:27 -0800, Josh Berkus wrote:
! #max_wal_size = 1GB# in logfile segments
Independent of the rest of the changes, the in logfile segments bit
should probably be changed.
Point! Although I think
On 3/2/15 3:56 PM, Andres Freund wrote:
On 2015-03-02 16:42:35 -0500, Robert Haas wrote:
On Tue, Feb 3, 2015 at 10:12 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Two reasons this isn't terribly compelling are (1) it's creating a
join in a place where the planner can't possibly see it and optimize
On 2015-03-03 08:59:30 +0900, Michael Paquier wrote:
Already mentioned upthread, but I agree with Fujii-san here: adding
information related to the state of a block image in
XLogRecordBlockHeader makes little sense because we are not sure to
have a block image, perhaps there is only data
On Tue, Mar 3, 2015 at 9:24 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2015-03-03 08:59:30 +0900, Michael Paquier wrote:
Already mentioned upthread, but I agree with Fujii-san here: adding
information related to the state of a block image in
XLogRecordBlockHeader makes little sense
On 2/27/15 11:27 PM, Stephen Frost wrote:
@@ -344,6 +346,21 @@ ProcessConfigFile(GucContext context)
PGC_BACKEND,
PGC_S_DYNAMIC_DEFAULT);
}
+ guc_file_variables = (ConfigFileVariable *)
+ guc_malloc(FATAL,
On 03/02/2015 03:18 PM, Josh Berkus wrote:
Attached.
Per discussion on the thread Redesigning checkpoint_segments this
raises the default for the new parameter max_wal_size to 1GB.
Seems too small to add it to the CF, but if you want me to, I will.
Ooops, patch didn't include the docs
On Tue, Mar 3, 2015 at 5:17 AM, Rahila Syed rahilasye...@gmail.com wrote:
Hello,
When I test the WAL or replication related features, I usually run
make installcheck and pgbench against the master at the same time
after setting up the replication environment.
I will conduct these tests before
On 03/03/2015 01:43 AM, Andres Freund wrote:
On 2015-03-02 15:40:27 -0800, Josh Berkus wrote:
! #max_wal_size = 1GB # in logfile segments
Independent of the rest of the changes, the in logfile segments bit
should probably be changed.
The base unit is still logfile
Heikki,
On Monday, March 2, 2015, Heikki Linnakangas hlinn...@iki.fi wrote:
On 03/02/2015 08:05 PM, Josh Berkus wrote:
On 03/02/2015 05:38 AM, Stephen Frost wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Mon, Mar 2, 2015 at 6:43 AM, Heikki Linnakangas hlinn...@iki.fi
wrote:
On
Hi David ;-)
On 2.3.2015 20:19, David Kubečka wrote:
The question is why optimizer, or rather the cost estimator,
produced so much different estimates upon very small change in input.
Moreover it seems that the main culprit of bad estimates isn't
actually directly related to outer table, but
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Qingqing Zhou wrote:
Do we think above scenario is something we shall worry about? Especially
for large databases.
IMO in theory it sucks that toast values use the shared OID generator,
though in practice I have never seen a problem due to
Jan de Visser j...@de-visser.net wrote:
On March 2, 2015 09:50:49 AM Tom Lane wrote:
However, you could and should use pg_malloc0, which takes care
of that for you...
I am (using pg_malloc, that is). So, just to be sure: pg_malloc
memsets the block to 0, right?
I think you may have misread
Hi,
Kathy (CCed) just found a bug in BDR that turned out to actually be a
bug in postgres.
CREATE VIEW v_03 AS
SELECT * FROM (SELECT '2' ORDER BY 1) s;
postgres[l]=# \d+ v_03
View public.v_03
┌──┬──┬───┬──┬─┐
│ Column │ Type │
On Mon, Mar 2, 2015 at 12:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
There is an issue if you do a dump and restore: the toast OIDs used in any
one table will be consecutive after that, because we load all the data for
each table sequentially.
With these consecutive oids, the aggravated oid
On 2 March 2015 at 12:48, Shigeru Hanada shigeru.han...@gmail.com wrote:
Attached is the revised/rebased version of the $SUBJECT.
This patch is based on Kaigai-san's custom/foreign join patch, so
please apply it before this patch. In this version I changed some
points from original
Jan de Visser j...@de-visser.net writes:
4/ Question: Can I assume pg_malloc allocated memory is set to zero? If not,
is it OK to do a memset(..., 0, ...)? I don't have much experience on any of
the esoteric platforms pgsql supports...
No, you need the memset. You might accidentally get
Eric Grinstein e...@aluno.puc-rio.br wrote:
I would be very interested in tracking the staleness of the MV.
You see, I work in a research group in database tuning, and we
have implemented some solutions to take advantage of MV's and
speed up queries.
Please be sure, right up front, that
On Thu, Feb 12, 2015 at 10:50 PM, Marco Nenciarini
marco.nenciar...@2ndquadrant.it wrote:
Hi,
I've attached an updated version of the patch.
basebackup.c:1565: warning: format '%lld' expects type 'long long
int', but argument 8 has type '__off_t'
basebackup.c:1565: warning: format '%lld'
Hi,
2015-02-20 16:19 GMT+01:00 Tom Lane t...@sss.pgh.pa.us:
2. Semantics. The existing GUC_REPORT variables are all things that
directly relate to client-visible behavior, eg how values of type
timestamp will be interpreted and printed. search_path is no such thing,
so it's hard to make a
I seem to be getting a problem with whole-row references:
# SELECT p.name, c.country, e.pet_name, p FROM pets e INNER JOIN people p on
e.person_id = p.id inner join countries c on p.country_id = c.id;
ERROR: table r has 3 columns available but 4 columns specified
CONTEXT: Remote SQL
So earlier someone commented that using lists list_nth() seemed odd and a
tuplestore might be better. In fact using lists this way is O(n^2). I've
done some quick tests and it doesn't start being a problem until about
10,000 lines which obviously isn't a terribly common way to use
On 2 March 2015 at 14:07, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
I seem to be getting a problem with whole-row references:
# SELECT p.name, c.country, e.pet_name, p FROM pets e INNER JOIN people
p on
e.person_id = p.id inner join countries c on p.country_id = c.id;
ERROR: table r
Greg,
* Greg Stark (st...@mit.edu) wrote:
On Mon, Mar 2, 2015 at 6:36 AM, Haribabu Kommi kommi.harib...@gmail.com
wrote:
Loading pg_hba.conf during SIGHUP in the backends will solve the
problem of displaying the
data which is not yet loaded. This change may produce a warning if it
* Robert Haas (robertmh...@gmail.com) wrote:
On Mon, Mar 2, 2015 at 6:43 AM, Heikki Linnakangas hlinn...@iki.fi wrote:
On 02/26/2015 01:32 AM, Josh Berkus wrote:
But ... I thought we were going to raise the default for max_wal_size to
something much higher, like 1GB? That's what was
On 02/26/2015 01:32 AM, Josh Berkus wrote:
But ... I thought we were going to raise the default for max_wal_size to
something much higher, like 1GB? That's what was discussed on this thread.
No conclusion was reached on that. Me and some others were against
raising the default, while others
On Mon, Mar 2, 2015 at 8:37 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
On 03/02/2015 11:53 AM, Fujii Masao wrote:
On Sat, Feb 28, 2015 at 5:00 AM, Josh Berkus j...@agliodbs.com wrote:
On 11/10/2014 10:54 AM, Magnus Hagander wrote:
On Mon, Nov 10, 2014 at 7:48 PM, Heikki Linnakangas
On Mon, Mar 2, 2015 at 6:36 AM, Haribabu Kommi kommi.harib...@gmail.com
wrote:
Loading pg_hba.conf during SIGHUP in the backends will solve the
problem of displaying the
data which is not yet loaded. This change may produce a warning if it
fails to load pg_hba.conf in the backends.
This
On Mon, Mar 2, 2015 at 6:43 AM, Heikki Linnakangas hlinn...@iki.fi wrote:
On 02/26/2015 01:32 AM, Josh Berkus wrote:
But ... I thought we were going to raise the default for max_wal_size to
something much higher, like 1GB? That's what was discussed on this
thread.
No conclusion was reached
Attached is the revised/rebased version of the $SUBJECT.
This patch is based on Kaigai-san's custom/foreign join patch, so
please apply it before this patch. In this version I changed some
points from original postgres_fdw.
1) Disabled SELECT clause optimization
~9.4 postgres_fdw lists only
On 03/02/2015 11:53 AM, Fujii Masao wrote:
On Sat, Feb 28, 2015 at 5:00 AM, Josh Berkus j...@agliodbs.com wrote:
On 11/10/2014 10:54 AM, Magnus Hagander wrote:
On Mon, Nov 10, 2014 at 7:48 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
pg_standby is more configurable than the built-in
On Sat, Feb 28, 2015 at 5:00 AM, Josh Berkus j...@agliodbs.com wrote:
On 11/10/2014 10:54 AM, Magnus Hagander wrote:
On Mon, Nov 10, 2014 at 7:48 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
pg_standby is more configurable than the built-in standby_mode=on. You can
set the sleep
On Tue, Feb 24, 2015 at 6:44 PM, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp wrote:
Hello, the attached is the v4 patch that checks feedback timing
every WAL segments boundary.
At Fri, 20 Feb 2015 17:29:14 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp
On 26 February 2015 at 09:27, Dean Rasheed dean.a.rash...@gmail.com wrote:
I think this should probably be committed as 2 separate patches...
On closer inspection, the 2 parts are interrelated since the new
self-join test that tests the inheritance planner changes also
requires the rewriter
On Fri, Feb 27, 2015 at 12:44 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Fri, Feb 27, 2015 at 8:01 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Fri, Feb 27, 2015 at 6:54 AM, Rahila Syed rahilasye...@gmail.com wrote:
Even this patch doesn't work fine. The standby emit the
Alvaro,
I thought I saw a comment about using underscore to separate words in
privilege names, such as EXCLUSIVE_BACKUP rather than running it all
together. Was that idea discarded?
I'm not sure there was an actual discussion on the topic. Though, at one
point I had proposed it as one of
Adam Brightwell wrote:
Alvaro,
I thought I saw a comment about using underscore to separate words
in privilege names, such as EXCLUSIVE_BACKUP rather than running it
all together. Was that idea discarded?
I'm not sure there was an actual discussion on the topic. Though, at one
point
Il 02/03/15 14:21, Fujii Masao ha scritto:
On Thu, Feb 12, 2015 at 10:50 PM, Marco Nenciarini
marco.nenciar...@2ndquadrant.it wrote:
Hi,
I've attached an updated version of the patch.
basebackup.c:1565: warning: format '%lld' expects type 'long long
int', but argument 8 has type '__off_t'
On 2015-03-02 19:11:15 +0200, Heikki Linnakangas wrote:
Come to think of it, it would be cleaner anyway to move the
XLogBeginInsert() and XLogInsert() calls inside XactEmitCommitRecord. Then
those structs don't need to be static either.
That was my first thought as well - but it doesn't easily
On 2015-02-25 12:10:42 +0100, Andres Freund wrote:
On 2015-02-24 20:51:42 +0200, Heikki Linnakangas wrote:
Regarding XactEmitCommitRecord and XactEmitAbortRecord, I wonder if you
could pass an xl_xact_parsed/abort_commit struct to them, instead of the
individual fields? You could then also
On Wed, Feb 25, 2015 at 4:58 PM, Jim Nasby jim.na...@bluetreble.com wrote:
On 2/24/15 8:28 AM, Sawada Masahiko wrote:
According to the above discussion, VACUUM and REINDEX should have
trailing options. Tom seems (to me) suggesting that SQL-style
(bare word preceded by WITH) options and Jim
Stephen Frost sfr...@snowman.net writes:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
If we were choosing those names nowadays, would we choose CREATEDB at
all in the first place? I think we'd go for something more verbose,
probably CREATE_DATABASE. (CREATEROLE is not as old as
On Mon, Mar 2, 2015 at 1:42 PM, Greg Stark st...@mit.edu wrote:
So earlier someone commented that using lists list_nth() seemed odd and a
tuplestore might be better. In fact using lists this way is O(n^2). I've
done some quick tests and it doesn't start being a problem until about
10,000
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Adam Brightwell wrote:
I'm not sure there was an actual discussion on the topic. Though, at one
point I had proposed it as one of the forms of this attribute. Personally,
I think it is easier to read with the underscore. But, ultimately,
On March 2, 2015 09:50:49 AM Tom Lane wrote:
However, you could and should use pg_malloc0, which takes care of that
for you...
I am (using pg_malloc, that is). So, just to be sure: pg_malloc memsets the
block to 0, right?
My question was more along the lines if memsetting to 0 to ensure that
On 03/02/2015 06:51 PM, Andres Freund wrote:
On 2015-02-25 12:10:42 +0100, Andres Freund wrote:
On 2015-02-24 20:51:42 +0200, Heikki Linnakangas wrote:
Regarding XactEmitCommitRecord and XactEmitAbortRecord, I wonder if you
could pass an xl_xact_parsed/abort_commit struct to them, instead of
Hi,
On 2015-02-15 01:48:15 -0300, Alvaro Herrera wrote:
This is a repost of the patch to add CREATE command deparsing support to
event triggers. It now supports not only CREATE but also ALTER and
other commands such as GRANT/REVOKE, COMMENT ON and SECURITY LABEL.
This patch series is broken
On 03/02/2015 07:14 PM, Andres Freund wrote:
On 2015-03-02 19:11:15 +0200, Heikki Linnakangas wrote:
Come to think of it, it would be cleaner anyway to move the
XLogBeginInsert() and XLogInsert() calls inside XactEmitCommitRecord. Then
those structs don't need to be static either.
That was my
Jan de Visser j...@de-visser.net writes:
On March 2, 2015 09:50:49 AM Tom Lane wrote:
However, you could and should use pg_malloc0, which takes care of that
for you...
I am (using pg_malloc, that is). So, just to be sure: pg_malloc memsets the
block to 0, right?
No, it doesn't, but
On March 2, 2015 12:44:40 PM Tom Lane wrote:
No, it doesn't, but pg_malloc0 does. Consult the code if you're confused:
src/common/fe_memutils.c
Doh! I read pg_malloc( ), not pg_malloc0.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
If we were choosing those names nowadays, would we choose CREATEDB at
all in the first place? I think we'd go for something more verbose,
probably
On 02/21/2015 10:41 PM, Peter Geoghegan wrote:
On Sat, Feb 21, 2015 at 11:15 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
What I had in mind is that the winning inserter waits on the other
inserter's token, without super-deleting. Like all inserts do today. So the
above scenario
On Tue, Feb 24, 2015 at 12:13:17PM +0300, Vladimir Borodin wrote:
20 февр. 2015 г., в 18:21, Bruce Momjian br...@momjian.us написал(а):
On Fri, Feb 20, 2015 at 09:45:08AM -0500, Bruce Momjian wrote:
#3 bothered me as well because it was not specific enough. I like
On 02/17/2015 02:11 AM, Peter Geoghegan wrote:
Whatever works, really. I can't say that the performance implications
of acquiring that hwlock are at the forefront of my mind. I never
found that to be a big problem on an 8 core box, relative to vanilla
INSERTs, FWIW - lock contention is not
Stephen Frost wrote:
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
That being so, I would consider the idea that the NO bit is a separate
word rather than run together with the actual privilege name. And given
that CREATE has all the options default to NO, there is no need
On Sun, Mar 1, 2015 at 1:42 PM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Feb 28, 2015 at 12:06 PM, Stephen Frost sfr...@snowman.net wrote:
I took a look through the patch and the discussion and it certainly
seems ready to me. I agree with Robert- let's go ahead and get this in
and
Hi all,
I have encountered a performance problem with relatively simple query,
which I think is caused by the overly pesimistic estimates in optimizer. I
have originally run into this issue on a table few GBs large, but it can be
reproduced with much smaller table as follows:
-- Setup main fact
On Mon, Mar 2, 2015 at 4:36 PM, Greg Stark st...@mit.edu wrote:
So I didn't get the memo about SFRM_Materialize. Here's a rewrite of this
using that interface which seems to test ok up to 100k. At that point I start
running into memory errors on reading the HBA file so I guess that's an
On Mon, Mar 2, 2015 at 11:20 AM, Heikki Linnakangas hlinn...@iki.fi wrote:
Are we OK with a 10% overhead, caused by the locking? That's probably
acceptable if that's what it takes to get UPSERT. But it's not OK just to
solve the deadlock issue with regular insertions into a table with exclusion
* Greg Stark (st...@mit.edu) wrote:
On Mon, Mar 2, 2015 at 4:36 PM, Greg Stark st...@mit.edu wrote:
So I didn't get the memo about SFRM_Materialize. Here's a rewrite of this
using that interface which seems to test ok up to 100k. At that point I
start running into memory errors on
On Mon, Mar 2, 2015 at 7:42 PM, Stephen Frost sfr...@snowman.net wrote:
Uh, maybe because it's trying to allocate over 1GB and palloc() doesn't
support that?
Nobody's allocating anything that big. It's a list of 25,000 pointers
to 472-byte structs. That should add up to about 11MB. Instead the
Kyotaro HORIGUCHI wrote:
Hello, thank you for the comment.
Looking at this a bit, I'm not sure completely replacing RoleId with a
node is the best idea; some of the users of that production in the
grammar are okay with accepting only normal strings as names, and don't
need all the
Greg Stark wrote:
Hm. I'm wondering why I'm getting out of memory errors now with just
25k lines in pg_hba.conf. It looks like the HbaLine struct is only
472 bytes so the list should only be occupying about 11MB. In fact
it's occupying about a gigabyte:
Maybe it's leaking heavily while
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Let's go with the NO_ prefix then ... that seems better to me than no
separator.
Works for me.
Thanks!
Stephen
signature.asc
Description: Digital signature
* Michael Paquier (michael.paqu...@gmail.com) wrote:
On Mon, Mar 2, 2015 at 6:27 AM, Stephen Frost sfr...@snowman.net wrote:
Please see the latest version of this, attached. I've removed the left
join, re-used the 'query' buffer (instead of destroying and recreating
it), and added a bit of
One scenario is to use an oid to identify a toast value. As the oid
generation is mono increased within a database instance, it can gets wrap
around after 2^32 generations. After that:
1. GetNewOidWithIndex() could gets unbounded performance as it needs to by
pass already in use values of its own.
On 03/02/2015 09:29 PM, Peter Geoghegan wrote:
On Mon, Mar 2, 2015 at 11:20 AM, Heikki Linnakangas hlinn...@iki.fi wrote:
Are we OK with a 10% overhead, caused by the locking? That's probably
acceptable if that's what it takes to get UPSERT. But it's not OK just to
solve the deadlock issue with
Qingqing Zhou wrote:
One scenario is to use an oid to identify a toast value. As the oid
generation is mono increased within a database instance, it can gets wrap
around after 2^32 generations. After that:
1. GetNewOidWithIndex() could gets unbounded performance as it needs to by
pass already
Hello,
When I test the WAL or replication related features, I usually run
make installcheck and pgbench against the master at the same time
after setting up the replication environment.
I will conduct these tests before sending updated version.
Seems this increases the header size of WAL record
On 03/02/2015 08:05 PM, Josh Berkus wrote:
On 03/02/2015 05:38 AM, Stephen Frost wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Mon, Mar 2, 2015 at 6:43 AM, Heikki Linnakangas hlinn...@iki.fi wrote:
On 02/26/2015 01:32 AM, Josh Berkus wrote:
But ... I thought we were going to raise
83 matches
Mail list logo
