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
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
. 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
.
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
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
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
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
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
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
://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
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
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
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
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
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
://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
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
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
-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
/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
. Is there a standard benchmark to
measure that?
--
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
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
.
--
Ants Aasma
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
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
the variability will make
the result pretty much useless. For example in the I/O case, a pretty typical
load can have 1% of timings be 3 orders of magnitude longer than median.
--
Ants Aasma
#include stdio.h
#include sys/time.h
typedef long long int64;
typedef unsigned long long uint64;
typedef long int32
is a patch, if anyone wishes
to give it a go.
--
Ants Aasma
diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c
index 19ff524..59ff996 100644
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -1324,7 +1324,7 @@ GetSnapshotData
and avoid issues with someone changing the system time while
you're timing. This precision does require OS and hardware cooperation,
because of CPU offsets, TSC's changing frequencies, stopping, etc.
--
Ants Aasma
[1]
https://github.com/torvalds/linux/blob/master/arch/x86/kernel/tsc_sync.c#L143
improvement in generated code quality.
--
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
that they don’t change any of the
basic characteristics.
Your thoughts?
--
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 Thu, Sep 8, 2011 at 5:28 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Sep 8, 2011 at 9:26 AM, Ants Aasma ants.aa...@eesti.ee wrote:
When go try to find the new csnmin
and discover that a backend has a csnmin that is too old, we go through
the snapshots of that backend and convert
in, but in hindsight
seems a bit too much for a first try.
--
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
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
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
201 - 247 of 247 matches
Mail list logo
