insight what is behind the CPU overhead?
Maybe the solution is to make WAL insertion cheap enough to not
matter. That won't be easy, but neither are the alternatives.
Regards,
Ants Aasma
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
/message-id/CA+CSw_tEpJ=md1zgxPkjH6CWDnTDft4gBi=+p9snoc+wy3p...@mail.gmail.com
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, Aug 30, 2013 at 1:30 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-08-30 01:10:40 +0300, Ants Aasma wrote:
On Fri, Aug 30, 2013 at 12:33 AM, Andres Freund and...@2ndquadrant.com
wrote:
FWIW, WAL is still the major bottleneck for INSERT heavy workloads. The
per CPU
the speedup at 4x and has large
caveats with the extra lookup tables. A 28x speedup might be worth the
extra effort.
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
between 1 and 2 user configurable (it seems to me
that it could even be changed without a restart).
Thoughts?
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
a snapshot before altering and passing this to the hook. Would there
be other issues besides performance? If the snapshot is taken only when
there is a hook present then the performance can be fixed later.
Regards,
Ants Aasma
On Wed, Jul 17, 2013 at 1:54 PM, Greg Smith g...@2ndquadrant.com wrote:
On 7/16/13 11:36 PM, Ants Aasma wrote:
As you know running a full suite of write benchmarks takes a very long
time, with results often being inconclusive (noise is greater than
effect we are trying to measure).
I
the equivalent thing in a slightly
different way.
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
.
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
On Tue, Jul 16, 2013 at 9:17 PM, Greg Smith g...@2ndquadrant.com wrote:
On 7/16/13 12:46 PM, Ants Aasma wrote:
Spread checkpoints sprinkles the writes out over a long
period and the general tuning advice is to heavily bound the amount of
memory the OS willing to keep dirty.
That's arguing
. A read barrier is
enough here unless there is some other undocumented interaction. I
don't think it matters for performance, but it seems like good
practice to have the barriers exactly matching the documentation.
Regards,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener
memory
locations. This way all memory locations in xlog buffer page are
stored exactly once and there is no data race between writes making it
possible to omit the barrier from GetXLogBuffer.
WaitXLogInsertionsToFinish() takes care of the memory barrier for
XlogWrite().
Regards,
Ants Aasma
,
Ants Aasma
.
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
and incremental changes to rewind it to
the previous version.
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
others need
geographic distribution and resilience to network problems. It's
fundamentally impossible to provide both with the same solution.
[1]
http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en//archive/spanner-osdi2012.pdf
Regards,
Ants Aasma
lists of running transactions.
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
proposed.
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
that commiters acquire ProcArrayLock, and that
can be different from the order of WALInsertLock that determines the
ordering of LSNs, whereas visibility on the slave instance is
determined purely by WAL LSN order.
Regards,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700
On Jun 13, 2013 4:18 AM, Stephen Frost sfr...@snowman.net wrote:
* Ants Aasma (a...@cybertec.at) wrote:
In a cluster setting you take the CSN value on the master, then before
starting execution on a standby you wait until that the standby has
replayed enough WAL to reach the CSN point read
. If the
ensuing discussion doesn't find any major showstoppers then I will
start to work on a patch bit-by-bit.
Bit-by-bit? Reminds me of punched cards. I don't think we accept patches
in that format. :-)
we have a small one in the family.
Congratulations on that one.
Thanks,
Ants Aasma
On Fri, Jun 7, 2013 at 3:47 PM, Greg Stark st...@mit.edu wrote:
On Thu, Jun 6, 2013 at 11:42 PM, Ants Aasma a...@cybertec.at wrote:
To refresh your memory the basic idea is to change visibility
determination to be based on a commit sequence number (CSN for short)
- a 8 byte number incremented
major showstoppers then I will
start to work on a patch bit-by-bit. It might take a while though as
my free hacking time has been severely cut down since we have a small
one in the family.
Regards,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http
defeat the careful cost based
throttling that PostgreSQL does by periodically dumping a large
portion of dirty pages into the write queue at once. That does nasty
things to query latencies as evidenced by the work on checkpoint
spreading.
Regards,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
not needed so future refactorings don't create a data race.
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
of
operations on old cluster after new cluster forked off?
Truncate and all kinds of DROP come to mind, also table rewrites from
ALTER. The tool should probably just flag those relation files to be
copied wholesale.
Regards,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener
.
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
is a
small performance hit (10-20%) on todays CPUs for a small performance
gain on Haswell processors coming to market this year and up to a
theoretical 2x performance gain on future CPUs. Changing this is just
a matter of changing N_SUMS and updating documentation to match.
Regards,
Ants Aasma
On Apr 25, 2013 10:38 PM, Jeff Davis pg...@j-davis.com wrote:
On Tue, 2013-04-23 at 11:44 +0300, Ants Aasma wrote:
I will try to reword.
Did you have a chance to clarify this, as well as some of the other
documentation issues Simon mentioned here?
http://www.postgresql.org/message-id/CA
On Apr 23, 2013 10:17 AM, Jeff Davis pg...@j-davis.com wrote:
Attached is my reorganization of Ants's patch here:
http://www.postgresql.org/message-id/CA
+CSw_vinyf-w45i=M1m__MpJZY=e8s4nt_knnpebtwjtoa...@mail.gmail.com
Thanks for your help. Some notes below.
My changes:
* wrest the core
some infrastructure
complexity. If we set a hypothetical VECTORIZATION_FLAGS variable at
configure time, the performance is still there for those who need it
and can afford CPU specific builds.
Regards,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web
.
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
performance results prompted me to look
at what would have a lower overhead.
[1] http://create.stephan-brumme.com/crc32/
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
without much benefit in sight.
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
or so.
Forgive me, I can't seem to locate the patch for this? Re-post please,
just for clarity.
Not posted yet. I'm writing it as we speak. Will post within half an hour or so.
Regards,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http
On Mon, Apr 22, 2013 at 10:57 PM, Ants Aasma a...@cybertec.at wrote:
On Mon, Apr 22, 2013 at 10:54 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 22 April 2013 20:32, Florian Pflug f...@phlo.org wrote:
Assuming that we only ship a plain C implementation with 9.3, what
are we missing
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
On Thu, Apr 18, 2013 at 5:57 PM, Ants Aasma a...@cybertec.at wrote:
I'll generate an avalanche diagram for CRC32C too, but it will take a
while even if I use a smaller dataset.
Well that was useless... In CRC flipping each bit in the input flips
preset pattern of bits in the output regardless
of 65521 the
resulting checksum is called Adler-32. [1] However the quality of
Fletcher-32/Adler-32 is strictly worse than even the first iteration
of multiply-add based checksums proposed.
[1] http://en.wikipedia.org/wiki/Adler-32
Regards,
Ants Aasma
--
Cybertec Schönig Schönig GmbH
an implementation bug myself. I already checked the
test harness and that was all sane, compiler hadn't taken any
unforgivable liberties there. I will crosscheck the output with other
implementations to verify that the checksum is implemented correctly.
Regards,
Ants Aasma
--
Cybertec Schönig Schönig
On Thu, Apr 18, 2013 at 8:24 PM, Ants Aasma a...@cybertec.at wrote:
On Thu, Apr 18, 2013 at 8:15 PM, Florian Pflug f...@phlo.org wrote:
So either the CRC32-C polynomial isn't irreducible, or there something
fishy going on. Could there be a bug in your CRC implementation? Maybe
a mixup between
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 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
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
.
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
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
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
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
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
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
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
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
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
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
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
://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
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
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
,
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 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
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
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
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
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
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
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
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
.
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, 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
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
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
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
101 - 200 of 247 matches
Mail list logo
