comes along, page A is broken in the heap with no
double-write buffer backup nor anything to recover it by in the WAL.
--
Ants Aasma
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jan 4, 2012 at 3:49 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Dec 30, 2011 at 11:58 AM, Jeff Janes jeff.ja...@gmail.com wrote:
On 12/29/11, Ants Aasma ants.aa...@eesti.ee wrote:
Unless I'm missing something, double-writes are needed for all writes,
not only the first page
.
--
Ants Aasma
size. The increase in
memory usage should be a drop in the bucket for systems that have enough
transaction processing velocity for that to be a problem.
--
Ants Aasma
some field experience on any issues surrounding timing :)
Some implementation notes. This currently fails regression test
create_function_3, haven't looked into why yet.
I'll take a look at it.
Thanks again.
--
Ants Aasma
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
. Is there a standard benchmark to
measure that?
--
Ants Aasma
/available_clocksource
To switch the clocksource, just write the desired clocksource like this:
# echo hpet /sys/devices/system/clocksource/clocksource0/current_clocksource
Thanks,
Ants Aasma
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
-dimensional case and so people
will want to try different algorithms, or make different tradeoffs on
effort spent on constructing the histogram. Or even build one by hand.
Cheers,
Ants Aasma
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
to say that the histogram is mostly
useless. It seems to me that it mostly shows OS scheduling noise. I
would even say that the histogram output should be hidden behind an
command line option to avoid unnecessary confusion.
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener
overlap with other non-store
instructions.
[1] http://support.amd.com/us/Processor_TechDocs/25112.PDF
[2]
http://www.intel.com/content/dam/doc/manual/64-ia-32-architectures-optimization-manual.pdf
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http
of writing
transactions and hold snapshots open for a long time.
If anyone is interested I can do a slightly longer write up detailing
what I have worked out so far.
Ants Aasma
[1]
http://archives.postgresql.org/message-id/CA%2BTgmoaAjiq%3Dd%3DkYt3qNj%2BUvi%2BMB-aRovCwr75Ca9egx-Ks9Ag
this, but probably not by orders of magnitude.
Regards,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
this exact concept the black hole storage engine.
Regards,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
duplication in the
executor to be worth considering committing.
Regards,
Ants Aasma
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Nov 9, 2012 at 7:53 AM, Ants Aasma a...@cybertec.at wrote:
I also took two profiles (attached). AtEOXact_RelationCache seems to
be the culprit for the quadratic growth.
One more thing that jumps out as quadratic from the profiles is
transfer_all_new_dbs from pg_upgrade (20% of total CPU
.
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
meant that we could
start both postmasters and pipe the output from dump directly to
restore. This way the times for dumping and restoring can overlap.
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
--
Sent via pgsql
spclocation with database tablespace:
tblspace = PQgetvalue(res, relnum, i_spclocation);
/* if no table tablespace, use the database tablespace */
if (strlen(tblspace) == 0)
tblspace = dbinfo-db_tblspace;
Patch to fix this is attached.
Regards,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
be the minority anyway.
I won't really miss the per table stats. But if the pg_stat_statements
normalisation patch gets commited, it would be really neat to also
have IO waits there. It would be much easier to quickly diagnose what
is causing all this IO issues.
Thanks again,
Ants Aasma
--
Cybertec Schönig
aggregation.
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
diff --git a/src/backend/executor/nodeAgg.c b/src/backend/executor/nodeAgg.c
index c9aa921..53cdd09 100644
--- a/src/backend/executor/nodeAgg.c
+++ b/src/backend/executor
://utopia.duth.gr/~pefraimi/research/data/2007EncOfAlg.pdf
Cheers,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
available users get more flexibility.
The downside would be that we can't automatically make better sampling
methods available.
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
--
Sent via pgsql-hackers mailing list (pgsql
On Tue, Apr 24, 2012 at 10:31 AM, Sandro Santilli s...@keybit.net wrote:
On Tue, Apr 24, 2012 at 08:49:26AM +0200, Sandro Santilli wrote:
On Mon, Apr 23, 2012 at 08:34:44PM +0300, Ants Aasma wrote:
SELECT (SELECT reservoir_sample(some_table, 50) AS samples
FROM some_table WHERE ctid
the
bias. But that definitely isn't in the territory of simple and would
require rigorous statistical analysis.
And as for the monetary unit sampling, I agree that this is better
left as an optional extra.
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http
660ns timing overhead and 26.5s execution for your query, with timing
off execution time falls to 2.1s. For reference, tsc based timing
gives 19.2ns overhead and 2.3s execution time with timing.
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http
write.
4) Then ... segfault!
I cannot reproduce this. Attached is the script that I use for cascade
replication testing. With it I can see the replica connecting to
itself but no segfault.
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http
- replica_wal_sync -
master_commit_visible - commit_response
replica_wal_sync - replica_replay_wal - replica_commit_visible
If you issue a select on the replica after getting a commit response
from master you can see that the query getting a snapshot races with
replay of the commit record.
Ants Aasma
SELECT MIN(x) FROM test WHERE value BETWEEN :rangemin AND :rangemax;
I get the following results:
bitmap scan: 106 tps
index scan: 146 tps
index only scan: 653 tps
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
://www.almaden.ibm.com/cs/people/dmodha/ARC.pdf
Cheers,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
On Tue, May 22, 2012 at 11:36 PM, Ants Aasma a...@cybertec.at wrote:
... The free list
itself is a bit trickier, but if it's still necessary/useful then
SC-firstFreeBuffer and buf-freeNext are in effect a linked-list
stack, there should plenty of tested lock free algorithms floating
around
in
triggering the prefetchers. The CPU should be doing a lot better than
the current ~4.3GB/s when scanning buffer descriptors.
Of course not scanning at all or doing less scans at the expense of
more work in the inner loop would be even better.
Regards,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
the
transaction has been made visible. When someone flushes xlog, they
also check if it enables some background hinting and set the
corresponding flag for any backend with spare cycles to pick up.
Comments?
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web
. The latency vs throughput tradeoff could
possibly be per backend tunable.
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
to see where that train of
thought takes me.
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
be a larger problem and post a higher gain. Either way, I
think the nailing approach should be explored further, cacheline
ping-pong could still be a problem with higher number of processors
and losing the spinlock also loses the ability to detect contention.
Ants Aasma
--
Cybertec Schönig Schönig
and doesn't even aspire to be
portable yet. The main point was to see if there's any significant
performance to be gained by this method.
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
--
Sent via pgsql-hackers mailing list
in the docs that
would even hint that using -x shouldn't work to create a replica. Why
does it get confused and can we (easily) make it not get confused? At
the very least it needs a big fat warning in documentation for the -x
option that the resulting backup might not be usable as a standby.
Ants Aasma
?
It was dead code as far as I could tell. That change isn't actually
relevant for this patch because free-list management is still
protected by a lock (except the initial unlocked test that is
doublechecked under lock) and so doesn't need any adjustment.
Ants Aasma
--
Cybertec Schönig Schönig GmbH
On Mon, Jun 4, 2012 at 6:20 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Jun 4, 2012 at 11:25 PM, Ants Aasma a...@cybertec.at wrote:
On Thu, Sep 29, 2011 at 11:30 PM, Magnus Hagander mag...@hagander.net
wrote:
it doesn't say that is not possible to use this for a standby
server
this. I'll let you know if I find out how I
managed to create this error.
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
at 90tps with the stated configuration. Even when upping the
shared_buffers and enabling indexonlyscan I didn't see more than about
540tps per thread. The test is designed to exercise buffer eviction,
doing about 9800 buffer reads per transaction with 32MB of buffers.
Ants Aasma
--
Cybertec Schönig
.
It won't help set returning functions because the tuplestore for those
is fully materialized when the first row is fetched.
[1]
http://archives.postgresql.org/message-id/16737833.463.1332881676120.JavaMail.geo-discussion-forums%40pbcpw7
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse
. For me this was mostly a learning
experience for poking around in the planner.
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
marking this patch Rejected.
Thank you, for considering this and many thanks to Etsuro Fujita for reviewing.
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
--
Sent via pgsql-hackers mailing list (pgsql-hackers
be an optional WAL level on top of
hot_standby that would only be enabled if consistent visibility on
slaves is desired.
--
Ants Aasma
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
variant would say that if the commit
returns, and the server doesn't crash in the meantime, the commit would at
some point become visible. Maybe even that transactions that begin after the
commit returns become visible after that commit.
--
Ants Aasma
--
Sent via pgsql-hackers mailing list (pgsql
to specs it should take
4 or 8GB DIMMs in pairs. Sounds like the server is split into multiple
partitions.
--
Ants Aasma
[1] http://www.redbooks.ibm.com/redpapers/pdfs/redp4655.pdf
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
the necessary WAL
location.
--
Ants Aasma
applications to bump their
minimum db version. With operator(?) older JDBC clients can work too in
case the library version is fixed due to policies (I'm assuming here that
question marks already work within quoted identifiers/literals).
--
Ants Aasma
at
least one of my clients. That chapter is rather scarily complicated
compared to what's usually necessary.
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
--
Sent via pgsql-hackers mailing list (pgsql-hackers
so, if you restore with an
archive, but unnecessary.
The File System Level Backup chapter
(http://www.postgresql.org/docs/devel/static/backup-file.html) probably
should mention pg_basebackup -x, too.
Docs patches are welcome..
I will give it a shot.
Ants Aasma
--
Cybertec Schönig Schönig
of inserting an
end-of-backup record.
Thank you for explaining this, I can see how it works now. I'll see if
I can document this better so others won't have to go through as much
effort.
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql
until the next
refresh.
Sorry for weighing in late, but it seemed to me that this point didn't
get enough consideration.
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
--
Sent via pgsql-hackers mailing list (pgsql
, if we were to allow users manually maintaining
materialized view contents using DML commands, one would expect
TRUNCATE to mean make this matview empty, not make this matview
unavailable.
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql
widespread pattern with a
proliferation of mobile devices that need syncing.
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Thu, Mar 14, 2013 at 1:51 AM, Jim Nasby j...@nasby.net wrote:
On 3/12/13 9:10 AM, Ants Aasma wrote:
I have a feeling this is an increasingly widespread pattern with a
proliferation of mobile devices that need syncing.
If you're doing that with timestamps you're asking for a slew
,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Mar 15, 2013 at 2:32 PM, Ants Aasma a...@cybertec.at wrote:
I was able to coax GCC to vectorize the code in the attached patch
Now actually attached.
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
parallel
On Mon, Mar 18, 2013 at 2:04 AM, Greg Smith g...@2ndquadrant.com wrote:
On 3/15/13 5:32 AM, Ants Aasma wrote:
Best case using the CRC32 instruction would be 6.8 bytes/cycle [1].
But this got me thinking about how to do this faster...
[1]
http://www.drdobbs.com/parallel/fast-parallelized-crc
to go this route. My main worry is that there is a reasonably
large population of users out there that don't have that acceleration
capability and will have to settle for performance overhead 4x worse
than what you currently measured for a shared buffer swapping
workload.
Regards,
Ants Aasma
On Wed, Mar 20, 2013 at 12:52 AM, Greg Smith g...@2ndquadrant.com wrote:
On 3/19/13 6:08 PM, Ants Aasma wrote:
My main worry is that there is a reasonably
large population of users out there that don't have that acceleration
capability and will have to settle for performance overhead 4x worse
://en.wikipedia.org/wiki/LIRS_caching_algorithm
Regards,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
have reasonably good
error detection capabilities.
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On Fri, Mar 22, 2013 at 7:35 PM, Jeff Davis pg...@j-davis.com wrote:
On Fri, 2013-03-22 at 17:09 +0200, Ants Aasma wrote:
For performance the K8 results gave me confidence that we have a
reasonably good overview what the performance is like for the class of
CPU's that PostgreSQL is likely
mapping hash tables
already are. This should at the very least reduce contention for the
clock sweep even if it doesn't reduce work done per page miss.
[1] http://people.csail.mit.edu/mareko/spaa09-scalablerwlocks.pdf
Regards,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700
, named
LJQO:
https://github.com/alange0001/ljqo.git
Looks great. Do you happen to have any papers or insight into why SDP
works as well as it does? It isn't immediately clear to me why the
cheapest left-deep tree is a good heuristic start point for the
dynamic programming phase.
Regards,
Ants Aasma
that's the whole point of striping locks, the
critical section is usually cheaper than the cost of getting the cache
line in an exclusive state.
Regards,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
--
Sent via pgsql
. There
are many things that could be shifted to background if we knew it
could keep up, like hint bit setting on dirty buffers being flushed
out. But again, we have the issue of having good tests to see where
the changes hurt.
Regards,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to not be a loss
for small variable sized workloads will take considerable amount of
effort and code. Whereas it's quite easy for pipelined CRC32 and
Fletcher (or should I say Adler as we want to use mod 65521).
Regards,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
speedup or delay in eviction won't matter much.
Getting rid of memory barriers associated with locking in the clock
sweep will pipeline the loads and stores and so should bring on a good
performance increase for scanning large swathes of buffer headers.
Regards,
Ants Aasma
--
Cybertec Schönig
spinlock
anyway.
Regards,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
for is that we don't
have any blind spots for conceivable systemic errors. If we decide to
go with the SIMD variant then I intend to figure out what the blind
spots are and show that they don't matter.
Regards,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web
can take care of it by merging
writes. Additionally, contention for page level locks will increase with
page size, cache efficiency goes down. I would expect cases where larger
block size is a significant benefit to be very rare.
Regards,
Ants Aasma
the background writer would
function in this environment. But if redesigning the bgwriter
mechanism was on the table I thought I would throw the idea out here.
Regards,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
--
Sent via
On Fri, Apr 5, 2013 at 7:23 PM, Jeff Davis pg...@j-davis.com wrote:
On Tue, 2013-03-26 at 03:34 +0200, Ants Aasma wrote:
The main thing to look out for is that we don't
have any blind spots for conceivable systemic errors. If we decide to
go with the SIMD variant then I intend to figure out
for the sync replica. For
the second part, I think Heikkis work on enabling timeline switches
over streaming connections already ensure this (I haven't checked it
out in detail), but if not, shouldn't be too hard to add.
Regards,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700
On Mon, Apr 8, 2013 at 7:38 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-04-08 19:26:33 +0300, Ants Aasma wrote:
Not exactly. Sync-rep ensures that commit success is not sent to the
client before a synchronous replica acks the commit record. What
Samrat is proposing here is that WAL
On Fri, Apr 5, 2013 at 9:39 PM, Ants Aasma a...@cybertec.at wrote:
Unless somebody tells me not to waste my time I'll go ahead and come
up with a workable patch by Monday.
And here you go. I decided to be verbose with the comments as it's
easier to delete a comment to write one. I also left
not certain how much of the discovery
process is worth of README status. I think I will mostly go with why
the result is at is, skipping the journey. Any further questions would
certainly help as I think I gave a reasonably thorough explanation in
the patch.
Regards,
Ants Aasma
--
Cybertec Schönig
databases avoiding the need to
read in the whole database for differences is an obvious win.
Regards,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On Tue, Apr 9, 2013 at 5:35 AM, Ants Aasma a...@cybertec.at wrote:
Quick bench results on the worst case workload:
master no checksums: tps = 15.561848
master with checksums: tps = 1.695450
simd checksums: tps = 14.602698
For reference, results for the generic version, with default build
On Wed, Apr 10, 2013 at 4:36 AM, Jeff Davis pg...@j-davis.com wrote:
On Tue, 2013-04-09 at 05:35 +0300, Ants Aasma wrote:
And here you go. I decided to be verbose with the comments as it's
easier to delete a comment to write one. I also left in a huge jumble
of macros to calculate the contents
On Wed, Apr 10, 2013 at 12:25 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 10 April 2013 09:01, Ants Aasma a...@cybertec.at wrote:
Using SIMD for WAL is not a requirement at all; I just thought it might
be a nice benefit for non-checksum-enabled users in some later release.
I think we
after a VM goes
down and is migrated with the shared disk onto a new host.
Regards,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
to the client and waiting for WAL replication
before writing a data page are orthogonal features.
Regards,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
--
Sent via pgsql-hackers mailing list (pgsql-hackers
the resync
to restore high-availability safety in those circumstances is in many
cases a larger risk.
Regards,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On Thu, Apr 11, 2013 at 5:33 PM, Hannu Krosing ha...@2ndquadrant.com wrote:
On 04/11/2013 03:52 PM, Ants Aasma wrote:
On Thu, Apr 11, 2013 at 4:25 PM, Hannu Krosing ha...@2ndquadrant.com
wrote:
The proposed fix - halting all writes of data pages to disk and
to WAL files while waiting ACK
to get that into
the beta cycle too. What else are people aware of?
Page checksum algorithm needs to be decided before beta. If we release
an alpha without nailing it down testers need to be warned that
checksums are not likely to be upgradable.
Regards,
Ants Aasma
--
Cybertec Schönig Schönig
.
Regards,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
multiple uncorrelated single bit errors and
extremely bad at detecting repeating patterns of errors in low order
bits.
All in all I would say that the performance is worth the loss in
detection capability as we are not talking about using the checksum to
prove correctness.
Regards,
Ants Aasma
pmulld needs port 0 and pmullw
needs port 1. Currently the main loop takes 1 cycle per 16byte chunk,
any changes introducing conflicts there would cut the performance in
half.
Regards,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql
On Tue, Apr 16, 2013 at 5:05 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 9 April 2013 03:35, Ants Aasma a...@cybertec.at wrote:
On Fri, Apr 5, 2013 at 9:39 PM, Ants Aasma a...@cybertec.at wrote:
Unless somebody tells me not to waste my time I'll go ahead and come
up with a workable patch
On Tue, Apr 16, 2013 at 11:20 PM, Florian Pflug f...@phlo.org wrote:
On Apr13, 2013, at 17:14 , Ants Aasma a...@cybertec.at wrote:
Based on current analysis, it is particularly good at detecting single
bit errors, as good at detecting burst errors as can be expected from
16 bits
architectures at the expense of having only ok
performance on older AMD CPUs?
Also, any good suggestions where should we do CPU detection when we go
this route?
Regards,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
On Wed, Apr 17, 2013 at 6:54 PM, Florian Pflug f...@phlo.org wrote:
On Apr17, 2013, at 16:47 , Ants Aasma a...@cybertec.at wrote:
This made me remember, the issue I had was with high order bits, not
with low order ones, somehow I got them confused. The exact issue is
that the high order bits
On Thu, Apr 18, 2013 at 1:32 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Ants Aasma a...@cybertec.at writes:
I was thinking about something similar too. The big issue here is that
the parallel checksums already hide each other latencies effectively
executing one each of movdqu/pmullw/paddw each
On Thu, Apr 18, 2013 at 2:25 AM, Florian Pflug f...@phlo.org wrote:
On Apr17, 2013, at 23:44 , Ants Aasma a...@cybertec.at wrote:
Performance results:
Mul-add checksums: 12.9 bytes/s
FNV-1a checksums: 13.5 bytes/s
FNV-1a + srl-1: 7.4 bytes/s
Detection rates:
False positive rates
of the discussed algorithms
within an hour, leaving plenty of time in beta or in 9.4 to
accommodate the optimized versions. It's literally a dozen self
contained lines of code.
Regards,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
On Thu, Apr 18, 2013 at 5:08 AM, Greg Smith g...@2ndquadrant.com wrote:
On 4/17/13 8:56 PM, Ants Aasma wrote:
Nothing from the two points, but the CRC calculation algorithm can be
switched out for slice-by-4 or slice-by-8 variant. Speed up was around
factor of 4 if I remember correctly...I
1 - 100 of 247 matches
Mail list logo
