On 29/09/2014 9:00 AM, Merlin Moncure wrote:
On Fri, Sep 26, 2014 at 3:06 AM, Simon Riggs wrote:
The problem, as I see it, is different. We assume that if there are
100 distinct values and you use LIMIT 1 that you would only need to
scan 1% of rows. We assume that the data is arranged in the ta
now if you have any question about the paper
Thanks,
Reza
-Original Message-----
From: Ryan Johnson [mailto:ryan.john...@cs.utoronto.ca]
Sent: Saturday, July 26, 2014 4:51 PM
To: Reza Taheri
Cc: pgsql-performance@postgresql.org
Subject: Re: High rate of transaction failure with the Serializable
esults and ours
tell similar stories!
Thanks,
Reza
-Original Message-
From: pgsql-performance-ow...@postgresql.org [mailto:pgsql-
performance-ow...@postgresql.org] On Behalf Of Ryan Johnson
Sent: Saturday, July 26, 2014 2:06 PM
To: Reza Taheri
Cc: pgsql-performance@postgresql.org
Subject: R
reads.
Thanks,
Reza
-Original Message-
From: pgsql-performance-ow...@postgresql.org [mailto:pgsql-
performance-ow...@postgresql.org] On Behalf Of Ryan Johnson
Sent: Friday, July 25, 2014 2:36 PM
To: pgsql-performance@postgresql.org
Subject: Re: High rate of transaction failure wit
On 25/07/2014 2:58 PM, Reza Taheri wrote:
Hi Craig,
According to the attached SQL, each frame is a separate phase in the operation
and performs many different operations.
There's a *lot* going on here, so identifying possible interdependencies isn't
something I can do in a ten minute skim
rea
On 14/04/2014 4:30 PM, Ryan Johnson
wrote:
FYI, here's a plot of performance over time. Each point in the
graph is throughput (in tps) over a 10-second measurement (~20
minutes total), against a 12 WH TPC-C dataset with 24 clients
ba
On 14/04/2014 10:14 AM, Kevin Grittner
wrote:
Ryan Johnson wrote:
every time I shut down a database and bring it back up, SSI seems
to go slower.
There's one thing to rule out up front -- that would be a
long-lived pre
On 14/04/2014 10:14 AM, Kevin Grittner wrote:
Ryan Johnson wrote:
every time I shut down a database and bring it back up, SSI seems
to go slower.
There's one thing to rule out up front -- that would be a
long-lived prepared transaction.
Please post the output of these queries:
s
On 09/04/2014 5:21 PM, Bruce Momjian wrote:
On Mon, Apr 7, 2014 at 10:38:52AM -0400, Ryan Johnson wrote:
The two * entries were produced by runs under SI, and confirm that
the rest of the system has not been slowing down nearly as much as
SSI. SI throughput dropped by 5% as the database
Hi all,
(Referred here from pgsql-performance)
tl;dr: every time I shut down a database and bring it back up, SSI seems
to go slower. In order to avoid thousands of SSI aborts due to running
out of shared memory, I've had to set max_predicate_locks to several
thousand (2000 is tolerable, 8000
On 06/04/2014 10:55 AM, Tom Lane wrote:
Ryan Johnson writes:
I get a strange behavior across repeated runs: each 100-second run is a
bit slower than the one preceding it, when run with SSI (SERIALIZABLE).
... So the question: what should I look for to diagnose/triage this problem?
In the past
On 05/04/2014 10:25 PM, Ryan Johnson wrote:
Hi all,
Disclaimer: this question probably belongs on the hackers list, but
the instructions say you have to try somewhere else first... toss-up
between this list and a bug report; list seemed more appropriate as a
starting point. Happy to file a
On 06/04/2014 10:55 AM, Tom Lane wrote:
Ryan Johnson writes:
I get a strange behavior across repeated runs: each 100-second run is a
bit slower than the one preceding it, when run with SSI (SERIALIZABLE).
... So the question: what should I look for to diagnose/triage this problem?
In the past
On 06/04/2014 4:30 AM, Heikki Linnakangas wrote:
On 04/06/2014 05:25 AM, Ryan Johnson wrote:
I've tried linux perf, but all it says is that lots of time is going to
LWLock (but callgraph tracing doesn't work in my not-bleeding-edge
kernel).
Make sure you compile with the "
Hi all,
Disclaimer: this question probably belongs on the hackers list, but the
instructions say you have to try somewhere else first... toss-up between
this list and a bug report; list seemed more appropriate as a starting
point. Happy to file a bug if that's more appropriate, though.
This
15 matches
Mail list logo
