On 21/08/14 11:14, Mark Kirkwood wrote:
You didn't mention what
cpu this is for (or how many sockets etc), would be useful to know.
Just to clarify - while you mentioned that the production system was 40
cores, it wasn't immediately obvious that the same system was the source
of the
I have a table called stop_event (a stop event is one bus passing one bus
stop at a given time for a given route and direction), and I'd like to get
the average interval for each stop/route/direction combination.
A few hundred new events are written to the table once every minute. No
rows are
On Thu, Aug 21, 2014 at 4:29 PM, Eli Naeher enae...@gmail.com wrote:
Clearly the bulk of the time is spent sorting the rows in the original
table, and then again sorting the results of the subselect. But I'm afraid I
don't really know what to do with this information. Is there any way I can
On 08/21/2014 08:29 AM, Eli Naeher wrote:
With around 1.2 million rows, this takes 20 seconds to run. 1.2 million
rows is only about a week's worth of data, so I'd like to figure out a
way to make this faster.
Well, you'll probably be able to reduce the run time a bit, but even
with really
On 08/20/2014 06:14 PM, Mark Kirkwood wrote:
Notwithstanding the above results, my workmate Matt made an interesting
observation: the scaling graph for (our) 60 core box (HT off), looks
just like the one for our 32 core box with HT *on*.
Hmm. I know this sounds stupid and unlikely, but has
Upping work_mem did roughly halve the time, but after thinking about
Shaun's suggestion, I figured it's better to calculate this stuff once and
then store it. So here is how the table looks now:
Table public.stop_event
Column|
Oops, I forgot to include the test self-join query I'm using. It is simply:
SELECT se1.stop_time AS curr, se2.stop_time AS prev
FROM stop_event se1
JOIN stop_event se2 ON se1.previous_stop_event = se2.id;
On Thu, Aug 21, 2014 at 11:19 AM, Eli Naeher enae...@gmail.com wrote:
Upping work_mem
On Thu, Aug 21, 2014 at 7:19 PM, Eli Naeher enae...@gmail.com wrote:
However, when I try to do a
test self-join using it, Postgres does two seq scans across the whole table,
even though I have indexes on both id and previous_stop_event:
http://explain.depesz.com/s/ctck. Any idea why those
On 08/20/2014 07:40 PM, Bruce Momjian wrote:
On Wed, Aug 20, 2014 at 12:13:50PM -0700, Josh Berkus wrote:
On a read-write test, it's 10% faster with HT off as well.
Further, from their production machine we've seen that having HT on
causes the machine to slow down by 5X whenever you get more
On Thu, Aug 21, 2014 at 02:02:26PM -0700, Josh Berkus wrote:
On 08/20/2014 07:40 PM, Bruce Momjian wrote:
On Wed, Aug 20, 2014 at 12:13:50PM -0700, Josh Berkus wrote:
On a read-write test, it's 10% faster with HT off as well.
Further, from their production machine we've seen that having
On 08/21/2014 02:11 PM, Bruce Momjian wrote:
On Thu, Aug 21, 2014 at 02:02:26PM -0700, Josh Berkus wrote:
On 08/20/2014 07:40 PM, Bruce Momjian wrote:
On Wed, Aug 20, 2014 at 12:13:50PM -0700, Josh Berkus wrote:
On a read-write test, it's 10% faster with HT off as well.
Further, from their
On Thu, Aug 21, 2014 at 02:17:13PM -0700, Josh Berkus wrote:
Actually, I don't know that anyone has posted the benefits of HT. Link?
I want to compare results so that we can figure out what's different
between my case and theirs. Also, it makes a big difference if there is
an advantage
On Thu, Aug 21, 2014 at 3:02 PM, Josh Berkus j...@agliodbs.com wrote:
On 08/20/2014 07:40 PM, Bruce Momjian wrote:
I am also
unclear exactly what you tested, as I didn't see it mentioned in the
email --- CPU type, CPU count, and operating system would be the minimal
information required.
On Thu, Aug 21, 2014 at 3:26 PM, Scott Marlowe scott.marl...@gmail.com wrote:
On Thu, Aug 21, 2014 at 3:02 PM, Josh Berkus j...@agliodbs.com wrote:
On 08/20/2014 07:40 PM, Bruce Momjian wrote:
I am also
unclear exactly what you tested, as I didn't see it mentioned in the
email --- CPU type,
HT off is common knowledge for better benchmarking result
It's wise to use the qualifer 'for better benchmarking results'.
It's worth keeping in mind here that a benchmark is not the same as normal
production use.
For example, where I work we do lots of long-running queries in parallel over
On 08/21/2014 02:26 PM, Scott Marlowe wrote:
I'm running almost the exact same setup in production as a spare. It
has 4 of those CPUs, 256G RAM, and is currently set to use HT. Since
it's a spare node I might be able to do some testing on it as well.
It's running a 3.2 kernel right now. I
On 08/21/2014 03:51 PM, Josh Berkus wrote:
On 08/21/2014 02:26 PM, Scott Marlowe wrote:
I'm running almost the exact same setup in production as a spare. It
has 4 of those CPUs, 256G RAM, and is currently set to use HT. Since
it's a spare node I might be able to do some testing on it as well.
On 08/21/2014 04:08 PM, Steve Crawford wrote:
On 08/21/2014 03:51 PM, Josh Berkus wrote:
On 08/21/2014 02:26 PM, Scott Marlowe wrote:
I'm running almost the exact same setup in production as a spare. It
has 4 of those CPUs, 256G RAM, and is currently set to use HT. Since
it's a spare node I
On 22/08/14 11:29, Josh Berkus wrote:
On 08/21/2014 04:08 PM, Steve Crawford wrote:
On 08/21/2014 03:51 PM, Josh Berkus wrote:
On 08/21/2014 02:26 PM, Scott Marlowe wrote:
I'm running almost the exact same setup in production as a spare. It
has 4 of those CPUs, 256G RAM, and is currently set
On 08/21/2014 04:29 PM, Josh Berkus wrote:
On 08/21/2014 04:08 PM, Steve Crawford wrote:
On 08/21/2014 03:51 PM, Josh Berkus wrote:
On 08/21/2014 02:26 PM, Scott Marlowe wrote:
I'm running almost the exact same setup in production as a spare. It
has 4 of those CPUs, 256G RAM, and is
20 matches
Mail list logo
