On 05.03.2013 14:09, KONDO Mitsumasa wrote:
Hi,
Horiguch's patch does not seem to record minRecoveryPoint in ReadRecord();
Attempt patch records minRecoveryPoint.
[crash recovery - record minRecoveryPoint in control file - archive
recovery]
I think that this is an original intention of Heikki's
On 5 March 2013 22:02, Tom Lane t...@sss.pgh.pa.us wrote:
FWIW, my opinion is that doing anything like this in the planner is
going to be enormously expensive. Index matching is already pretty
expensive, and that has the saving grace that we only do it once per
base relation. Your sketch
On 5 March 2013 09:35, Heikki Linnakangas hlinnakan...@vmware.com wrote:
Are there objectors?
In addition to my hostility towards this patch in general, there are some
specifics in the patch I'd like to raise (read out in a grumpy voice):
;-) We all want to make the right choice here, so
On 5 March 2013 18:02, Jeff Davis pg...@j-davis.com wrote:
Fletcher is probably significantly faster than CRC-16, because I'm just
doing int32 addition in a tight loop.
Simon originally chose Fletcher, so perhaps he has more to say.
IIRC the research showed Fletcher was significantly faster
On 2013-03-06 13:21:27 +0900, Michael Paquier wrote:
Please find attached updated patch realigned with your comments. You can
find my answers inline...
The only thing that needs clarification is the comment about
UNIQUE_CHECK_YES/UNIQUE_CHECK_NO. Except that all the other things are
corrected
On Wed, Jan 23, 2013 at 7:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 23.01.2013 09:36, Alexander Korotkov wrote:
On Wed, Jan 23, 2013 at 6:08 AM, Tom Lanet...@sss.pgh.pa.us wrote:
The biggest problem is that I really don't care for the
On 2013-03-05 19:30:53 -0500, Tom Lane wrote:
One of the core problems for a writable-foreign-tables feature is how
to identify a previously-fetched row for UPDATE or DELETE actions.
In an ordinary Postgres table, we use the ctid system column for that,
but a remote table doesn't necessarily
Maciek Sakrejda wrote:
On Tue, Mar 5, 2013 at 12:03 AM, Albe Laurenz laurenz.a...@wien.gv.at wrote:
I don't think that it is about looking nice.
C doesn't promise you more than FLT_DIG or DBL_DIG digits of
precision, so PostgreSQL cannot either.
If you allow more, that would mean that if you
On Wed, Mar 6, 2013 at 12:35 PM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
In the context of postgres_fdw, I am not sure if we need an additional
system column like a node_id. Would there be a possibility where
tuples to-be-modified are coming from different foreign tables and at
runtime
It looks like the recent matview patch broke pg_dump in a way, which make
it impossible to dump 9.1 and 9.2 databases.
it fails with
pg_dump: [Archivierer (DB)] query failed: ERROR: function
pg_relation_is_scannable(oid) does not exist
Looking into this issue, it seems the version check in
On Wednesday, March 06, 2013 2:57 AM Heikki Linnakangas wrote:
On 04.03.2013 06:39, Amit Kapila wrote:
On Sunday, March 03, 2013 8:19 PM Craig Ringer wrote:
On 02/05/2013 11:53 PM, Amit Kapila wrote:
Performance data for the patch is attached with this mail.
Conclusions from the readings
On 06-Mar-2013, at 4:12 PM, Shigeru Hanada shigeru.han...@gmail.com wrote:
On Wed, Mar 6, 2013 at 12:35 PM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
In the context of postgres_fdw, I am not sure if we need an additional
system column like a node_id. Would there be a possibility where
On Wed, Mar 6, 2013 at 9:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
For postgres_fdw, that would really be enough, since it could just
cause a ctid column to be created with the usual definition. Then
it could put the remote ctid into the usual t_self field in returned
tuples.
I'm not sure
On 2013-03-06 20:59:37 +0900, Michael Paquier wrote:
OK. Patches updated... Please see attached.
With all the work done on those patches, I suppose this is close to being
something clean...
Yes, its looking good. There are loads of improvements possible but
those can very well be made
On Wed, Mar 6, 2013 at 9:09 PM, Andres Freund and...@2ndquadrant.comwrote:
On 2013-03-06 20:59:37 +0900, Michael Paquier wrote:
OK. Patches updated... Please see attached.
With all the work done on those patches, I suppose this is close to being
something clean...
Yes, its looking good.
On 2013-03-06 21:19:57 +0900, Michael Paquier wrote:
On Wed, Mar 6, 2013 at 9:09 PM, Andres Freund and...@2ndquadrant.comwrote:
On 2013-03-06 20:59:37 +0900, Michael Paquier wrote:
OK. Patches updated... Please see attached.
With all the work done on those patches, I suppose this is
* Alexander Korotkov (aekorot...@gmail.com) wrote:
Now, we probably don't have enough of time before 9.3 to solve an API
problem :(. It's likely we have to choose either commit to 9.3 without
clean API factorization or postpone it to 9.4.
As much as I'd like this to get in, I don't think
On 06.03.2013 10:41, Simon Riggs wrote:
On 5 March 2013 18:02, Jeff Davispg...@j-davis.com wrote:
Fletcher is probably significantly faster than CRC-16, because I'm just
doing int32 addition in a tight loop.
Simon originally chose Fletcher, so perhaps he has more to say.
IIRC the research
Simon Riggs si...@2ndquadrant.com writes:
On 5 March 2013 22:02, Tom Lane t...@sss.pgh.pa.us wrote:
FWIW, my opinion is that doing anything like this in the planner is
going to be enormously expensive.
As we already said: no MVs = zero overhead = no problem.
Well, in the first place that
On 03/05/2013 07:23 PM, Tom Lane wrote:
Maciek Sakrejda m.sakre...@gmail.com writes:
Thank you: I think this is what I was missing, and what wasn't clear
from the proposed doc patch. But then how can pg_dump assume that it's
always safe to set extra_float_digits = 3?
It's been proven (don't
On Tue, Mar 5, 2013 at 8:32 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
With these tweaks, I was able to make pglz-based delta encoding perform
roughly as well as Amit's patch.
Out of curiosity, do we know how pglz compares with other algorithms, e.g. lz4 ?
--
Sent via
On 2013-03-06 13:34:21 +0200, Heikki Linnakangas wrote:
On 06.03.2013 10:41, Simon Riggs wrote:
On 5 March 2013 18:02, Jeff Davispg...@j-davis.com wrote:
Fletcher is probably significantly faster than CRC-16, because I'm just
doing int32 addition in a tight loop.
Simon originally chose
Tatsuo Ishii is...@postgresql.org wrote:
Was the remaining work on docs done? I would like to test MVs and
am waiting for the docs completed.
I think they are done. If you notice anything missing or in need
of clarification please let me know. At this point missing docs
would be a bug in
Bernd Helmle maili...@oopsware.de wrote:
It looks like the recent matview patch broke pg_dump in a way, which make it
impossible to dump 9.1 and 9.2 databases.
it fails with
pg_dump: [Archivierer (DB)] query failed: ERROR: function
pg_relation_is_scannable(oid) does not exist
Looking
On Wed, Mar 6, 2013 at 8:32 AM, Joachim Wieland j...@mcknight.de wrote:
On Tue, Mar 5, 2013 at 8:32 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
With these tweaks, I was able to make pglz-based delta encoding perform
roughly as well as Amit's patch.
Out of curiosity, do we know how
Bernd Helmle maili...@oopsware.de wrote:
Looking into this issue, it seems the version check in getTables() of
pg_dump.c
is wrong. Shouldn't the check be
if (fout-remoteVersion = 90300)
{
}
since this is where pg_relation_is_scannable() is introduced?
Fixed.
Thanks for the report!
Kevin,
I haven't seen a reply to this. Were you able to give my notes below
any consideration?
On 2/15/13 12:44 PM, Peter Eisentraut wrote:
On 1/25/13 1:00 AM, Kevin Grittner wrote:
New patch rebased, fixes issues raised by Thom Brown, and addresses
some of your points.
This patch
On Tue, Mar 5, 2013 at 9:08 PM, Robert Haas robertmh...@gmail.com wrote:
All that having been said, it's hard for me to imagine that anyone
really cares about any of this until we have an incremental update
feature, which right now we don't. Actually, I'm betting that's going
to be
On Wed, Mar 06, 2013 at 01:34:21PM +0200, Heikki Linnakangas wrote:
On 06.03.2013 10:41, Simon Riggs wrote:
On 5 March 2013 18:02, Jeff Davispg...@j-davis.com wrote:
Fletcher is probably significantly faster than CRC-16, because I'm just
doing int32 addition in a tight loop.
Simon
On 2013-03-06 09:36:19 -0600, Merlin Moncure wrote:
On Wed, Mar 6, 2013 at 8:32 AM, Joachim Wieland j...@mcknight.de wrote:
On Tue, Mar 5, 2013 at 8:32 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
With these tweaks, I was able to make pglz-based delta encoding perform
roughly as
On 2013-03-06 11:21:21 -0500, Garick Hamlin wrote:
If picking a CRC why not a short optimal one rather than truncate CRC32C?
CRC32C is available in hardware since SSE4.2.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
Shigeru Hanada shigeru.han...@gmail.com writes:
I'm not sure whether postgres_fdw should support, but updatable views
have no system column including ctid. So, we need magic identifier,
perhaps it would be set of primary key value(s), to support updating
remote updatable views via foreign
On Wed, Mar 6, 2013 at 8:53 AM, Andres Freund and...@2ndquadrant.comwrote:
On 2013-03-06 09:36:19 -0600, Merlin Moncure wrote:
On Wed, Mar 6, 2013 at 8:32 AM, Joachim Wieland j...@mcknight.de wrote:
On Tue, Mar 5, 2013 at 8:32 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
With
On Wed, Mar 6, 2013 at 8:59 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
OK. Patches updated... Please see attached.
I found odd behavior. After I made REINDEX CONCURRENTLY fail twice,
I found that the index which was not marked as INVALID remained unexpectedly.
=# CREATE TABLE hoge (i
On 2013-03-06 09:08:10 -0800, Jeff Janes wrote:
On Wed, Mar 6, 2013 at 8:53 AM, Andres Freund and...@2ndquadrant.comwrote:
On 2013-03-06 09:36:19 -0600, Merlin Moncure wrote:
On Wed, Mar 6, 2013 at 8:32 AM, Joachim Wieland j...@mcknight.de wrote:
On Tue, Mar 5, 2013 at 8:32 AM, Heikki
On 2013-03-07 02:09:49 +0900, Fujii Masao wrote:
On Wed, Mar 6, 2013 at 8:59 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
OK. Patches updated... Please see attached.
I found odd behavior. After I made REINDEX CONCURRENTLY fail twice,
I found that the index which was not marked as
On 3/5/13 5:52 PM, Josh Berkus wrote:
More on this: the problem appears to be that the symbols for hstore are
loaded only if I've just just created the extension in that database:
I see. This is a problem with any kind of dynamically loadable module
that uses another module. The other module
On Wed, Mar 6, 2013 at 10:53 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-03-06 09:36:19 -0600, Merlin Moncure wrote:
On Wed, Mar 6, 2013 at 8:32 AM, Joachim Wieland j...@mcknight.de wrote:
On Tue, Mar 5, 2013 at 8:32 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
With
On Thu, Mar 7, 2013 at 2:17 AM, Andres Freund and...@2ndquadrant.com wrote:
Indexes:
hoge_pkey PRIMARY KEY, btree (i)
hoge_pkey_cct PRIMARY KEY, btree (i) INVALID
hoge_pkey_cct1 PRIMARY KEY, btree (i) INVALID
hoge_pkey_cct_cct PRIMARY KEY, btree (i)
Huh, why did that go
Kohei KaiGai kai...@kaigai.gr.jp writes:
2013/3/6 Tom Lane t...@sss.pgh.pa.us:
I think if we're going to support magic row identifiers, they need to
be actual system columns, complete with negative attnums and entries
in pg_attribute.
Sorry, -1 for me.
The proposed design tried to kill two
Peter,
At run time, this will sort itself out, because all the required modules
will be loaded. The problem is when you create the glue extension and
haven't invoked any code from any of the dependent extension in the
session.
Just invoking code doesn't seem to be enough. I tried just
On 2013-03-06 11:31:06 -0600, Merlin Moncure wrote:
On Wed, Mar 6, 2013 at 10:53 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-03-06 09:36:19 -0600, Merlin Moncure wrote:
On Wed, Mar 6, 2013 at 8:32 AM, Joachim Wieland j...@mcknight.de wrote:
On Tue, Mar 5, 2013 at 8:32 AM,
On 2013-03-06 09:53:29 -0800, Josh Berkus wrote:
Peter,
At run time, this will sort itself out, because all the required modules
will be loaded. The problem is when you create the glue extension and
haven't invoked any code from any of the dependent extension in the
session.
Just
On Mon, Mar 4, 2013 at 3:13 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 04.03.2013 20:58, Greg Smith wrote:
There
is no such thing as a stable release of btrfs, and no timetable for when
there will be one. I could do some benchmarks of that but I didn't think
they were very
Robert Haas robertmh...@gmail.com writes:
On Wed, Feb 27, 2013 at 8:58 AM, Stephen Frost sfr...@snowman.net wrote:
It's still entirely possible to get 99% done and then hit that last
tuple that you need a lock on and just tip over the lock_timeout_stmt
limit due to prior waiting and ending up
2013-03-06 19:53 keltezéssel, Tom Lane írta:
Robert Haas robertmh...@gmail.com writes:
On Wed, Feb 27, 2013 at 8:58 AM, Stephen Frost sfr...@snowman.net wrote:
It's still entirely possible to get 99% done and then hit that last
tuple that you need a lock on and just tip over the
There may be good reasons to reject this patch. Or there may not.
But I completely disagree with the idea that asking them to solve the
problem at the filesystem level is sensible.
Yes, can we get back to the main issues with the patch?
1) argument over whether the checksum is sufficient to
On Thu, Mar 7, 2013 at 2:09 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Mar 6, 2013 at 8:59 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
OK. Patches updated... Please see attached.
I found odd behavior. After I made REINDEX CONCURRENTLY fail twice,
I found that the index
On Mon, Mar 04, 2013 at 05:08:26PM -0300, Alvaro Herrera wrote:
Another point worth considering is that most of this is duplicated by
ecpg's libpgtypes. Do we want to fix that one too, or do we just let it
continue to be broken? I note that other bugs are already unfixed in
ecpg's copy. One
On Mon, Mar 04, 2013 at 05:55:26PM -0300, Alvaro Herrera wrote:
error codes for the caller to figure out. Maybe we could create a layer
on top of ereport, that gets both the error message, sqlstate etc, and
...
Couldn't we just create ecpg's own version of ereport, that does the right
thing
Michael Meskes wrote:
On Mon, Mar 04, 2013 at 05:08:26PM -0300, Alvaro Herrera wrote:
Another point worth considering is that most of this is duplicated by
ecpg's libpgtypes. Do we want to fix that one too, or do we just let it
continue to be broken? I note that other bugs are already
On 2013-03-07 02:34:54 +0900, Fujii Masao wrote:
On Thu, Mar 7, 2013 at 2:17 AM, Andres Freund and...@2ndquadrant.com wrote:
Indexes:
hoge_pkey PRIMARY KEY, btree (i)
hoge_pkey_cct PRIMARY KEY, btree (i) INVALID
hoge_pkey_cct1 PRIMARY KEY, btree (i) INVALID
Kevin Grittner kgri...@ymail.com wrote:
Tatsuo Ishii is...@postgresql.org wrote:
Was the remaining work on docs done? I would like to test MVs and
am waiting for the docs completed.
I think they are done. If you notice anything missing or in need
of clarification please let me know. At
On 2013-03-07 05:26:31 +0900, Michael Paquier wrote:
On Thu, Mar 7, 2013 at 2:34 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Mar 7, 2013 at 2:17 AM, Andres Freund and...@2ndquadrant.com
wrote:
Indexes:
hoge_pkey PRIMARY KEY, btree (i)
hoge_pkey_cct PRIMARY KEY,
On Mar 6, 2013, at 1:51 PM, Kevin Grittner kgri...@ymail.com wrote:
I also think that something should be done about the documentation
for indexes. Right now that always refers to a table. It would
clearly be awkward to change that to table or materialized view
everywhere. I wonder if most
Kevin Grittner kgri...@ymail.com wrote:
Tatsuo Ishii is...@postgresql.org wrote:
Was the remaining work on docs done? I would like to test MVs and
am waiting for the docs completed.
I think they are done. If you notice anything missing or in need
of clarification please let me know. At
Robert,
We've had a few EnterpriseDB customers who have had fantastically
painful experiences with PostgreSQL + ZFS. Supposedly, aligning the
ZFS block size to the PostgreSQL block size is supposed to make these
problems go away, but in my experience it does not have that effect.
So I think
On Wed, Mar 6, 2013 at 2:14 PM, Josh Berkus j...@agliodbs.com wrote:
Based on Smith's report, I consider (2) to be a deal-killer right now.
I was pretty depressed by those numbers, too.
The level of overhead reported by him would prevent the users I work
with from ever employing checksums on
On Wed, Mar 6, 2013 at 6:00 PM, Josh Berkus j...@agliodbs.com wrote:
We've had a few EnterpriseDB customers who have had fantastically
painful experiences with PostgreSQL + ZFS. Supposedly, aligning the
ZFS block size to the PostgreSQL block size is supposed to make these
problems go away,
On 03/06/2013 03:06 PM, Robert Haas wrote:
On Wed, Mar 6, 2013 at 6:00 PM, Josh Berkus j...@agliodbs.com wrote:
We've had a few EnterpriseDB customers who have had fantastically
painful experiences with PostgreSQL + ZFS. Supposedly, aligning the
ZFS block size to the PostgreSQL block size is
Andres Freund and...@2ndquadrant.com writes:
On 2013-03-06 11:21:21 -0500, Garick Hamlin wrote:
If picking a CRC why not a short optimal one rather than truncate CRC32C?
CRC32C is available in hardware since SSE4.2.
I think that should be at most a fourth-order consideration, since we
are not
Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Mar 5, 2013 at 7:36 AM, Kevin Grittner kgri...@ymail.com wrote:
Fujii Masao masao.fu...@gmail.com wrote:
When I accessed the materialized view in the standby server,
I got the following ERROR message. Looks odd to me. Is this a bug?
I found this sentence somewhat confusing:
It is possible for a column's value to change even when the trigger
is not fired,
http://www.postgresql.org/docs/devel/static/sql-createtrigger.html#SQL-CREATETRIGGER-NOTES
More precise would be something along the lines It is possible that
changes to
On 03/06/2013 07:34 PM, Heikki Linnakangas wrote:
It'd be difficult to change the algorithm in a future release without
breaking on-disk compatibility,
On-disk compatibility is broken with major releases anyway, so I don't
see this as a huge barrier.
--
Craig Ringer
On 2013-03-07 08:37:40 +0800, Craig Ringer wrote:
On 03/06/2013 07:34 PM, Heikki Linnakangas wrote:
It'd be difficult to change the algorithm in a future release without
breaking on-disk compatibility,
On-disk compatibility is broken with major releases anyway, so I don't
see this as a huge
On 3/6/13 1:34 PM, Robert Haas wrote:
We've had a few EnterpriseDB customers who have had fantastically
painful experiences with PostgreSQL + ZFS. Supposedly, aligning the
ZFS block size to the PostgreSQL block size is supposed to make these
problems go away, but in my experience it does not
On Thu, Mar 7, 2013 at 7:19 AM, Andres Freund and...@2ndquadrant.comwrote:
On 2013-03-07 05:26:31 +0900, Michael Paquier wrote:
On Thu, Mar 7, 2013 at 2:34 AM, Fujii Masao masao.fu...@gmail.com
wrote:
On Thu, Mar 7, 2013 at 2:17 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 03/07/2013 08:41 AM, Andres Freund wrote:
On 2013-03-07 08:37:40 +0800, Craig Ringer wrote:
On 03/06/2013 07:34 PM, Heikki Linnakangas wrote:
It'd be difficult to change the algorithm in a future release without
breaking on-disk compatibility,
On-disk compatibility is broken with major
On Thu, Mar 7, 2013 at 9:48 AM, Michael Paquier
michael.paqu...@gmail.comwrote:
On Thu, Mar 7, 2013 at 7:19 AM, Andres Freund and...@2ndquadrant.comwrote:
On 2013-03-07 05:26:31 +0900, Michael Paquier wrote:
On Thu, Mar 7, 2013 at 2:34 AM, Fujii Masao masao.fu...@gmail.com
wrote:
On
On Wed, Feb 27, 2013 at 8:58 AM, Stephen Frost sfr...@snowman.net wrote:
* Boszormenyi Zoltan (z...@cybertec.at) wrote:
But unlike statement_timeout,
with lock_timeout_stmt the statement can still finish after this limit
as it does useful work besides waiting for locks.
It's still entirely
On Sun, Jan 27, 2013 at 1:55 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
The part-1 patch adds catalog/objectaccess.c to have entrypoints of
object_access_hook, instead of simple macro definition, to simplify
invocations with arguments. It is just a replacement of existing
OAT_POST_CREATE and
On 3/4/13 7:04 PM, Daniel Farina wrote:
Corruption has easily occupied more than one person-month of time last
year for us.
Just FYI for anyone that's experienced corruption... we've looked into doing
row-level checksums at work. The only challenge we ran into was how to check
them when
On 3/6/13 1:14 PM, Josh Berkus wrote:
There may be good reasons to reject this patch. Or there may not.
But I completely disagree with the idea that asking them to solve the
problem at the filesystem level is sensible.
Yes, can we get back to the main issues with the patch?
1) argument
On 2/2/13 4:05 AM, Paul Norman wrote:
Hello,
After a discussion on IRC in #postgresql, I had a feature suggestion and it
was suggested I write it up here.
I have a large (200GB, 1.7b rows) table with a number of columns, but the
two of interest here are a hstore column, tags and a postgis
On 2/2/13 3:23 AM, Pavel Stehule wrote:
Hello
I propose enhancing GET DIAGNOSTICS statement about new field
PG_CONTEXT. It is similar to GET STACKED DIAGNOSTICS'
PG_EXCEPTION_CONTEXT.
Motivation for this proposal is possibility to get call stack for
debugging without raising exception.
This
On Sun, Jan 27, 2013 at 1:55 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
The part-2 patch adds new OAT_POST_ALTER event type, and
its relevant permission checks on contrib/sepgsql.
This documentation hunk is unclear:
+On xref linkend=sql-createfunction, literalinstall/ permission
+will
On 3/6/13 6:34 AM, Heikki Linnakangas wrote:
Another thought is that perhaps something like CRC32C would be faster to
calculate on modern hardware, and could be safely truncated to 16-bits
using the same technique you're using to truncate the Fletcher's
Checksum. Greg's tests showed that the
On 3/6/13 1:24 PM, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-03-06 11:21:21 -0500, Garick Hamlin wrote:
If picking a CRC why not a short optimal one rather than truncate CRC32C?
CRC32C is available in hardware since SSE4.2.
I think that should be at most a
On Wed, Mar 6, 2013 at 11:04 PM, Robert Haas robertmh...@gmail.com wrote:
When we first talked about this feature for
9.2, we were going to exclude hint bits from checksums, in order to
avoid this issue; what happened to that?
I don't think anyone ever thought that was a particularly
TL;DR summary: on a system I thought was a fair middle of the road
server, pgbench tests are averaging about a 2% increase in WAL writes
and a 2% slowdown when I turn on checksums. There are a small number of
troublesome cases where that overhead rises to closer to 20%, an upper
limit that's
On Wed, Mar 6, 2013 at 8:17 PM, Greg Smith g...@2ndquadrant.com wrote:
TL;DR summary: on a system I thought was a fair middle of the road server,
pgbench tests are averaging about a 2% increase in WAL writes and a 2%
slowdown when I turn on checksums. There are a small number of troublesome
On 3/5/13 9:07 AM, Amit Kapila wrote:
In v11 patch, I have changed name of directory to config.
For file name, currently I have not changed, but if you feel it needs to be
changed, kindly suggest any one of above or if any other better you have in
mind.
This seems fine for now. Hashing out
On 3/7/13 12:15 AM, Daniel Farina wrote:
I have only done some cursory research, but cpu-time of 20% seem to
expected for InnoDB's CRC computation[0]. Although a galling number,
this comparison with other systems may be a way to see how much of
that overhead is avoidable or just the price of
On Thursday, March 07, 2013 10:54 AM Greg Smith wrote:
On 3/5/13 9:07 AM, Amit Kapila wrote:
In v11 patch, I have changed name of directory to config.
For file name, currently I have not changed, but if you feel it needs
to be
changed, kindly suggest any one of above or if any other better
84 matches
Mail list logo
