Hi, all
My small thoughts about parallelizing single query.
AFAIK in the cases where it is needed, there is usually one single
operation that takes a lot of CPU, e.g. hashing or sorting. And this are
usually tasks that has well known algorithms to parallelize.
The main problem, as for me, is
Andy Colson wrote:
Yes, I agree... for today. If you gaze into 5 years... double the
core count (but not the speed), double the IO rate. What do you see?
Four more versions of PostgreSQL addressing problems people are having
right now. When we reach the point where parallel query is the
gnuo...@rcn.com writes:
Time for my pet meme to wiggle out of its hole (next to Phil's, and a
day later). For PG to prosper in the future, it has to embrace the
multi-core/processor/SSD machine at the query level. It has to. And
it has to because the Big Boys already do so, to some extent,
On Fri, 4 Feb 2011, Chris Browne wrote:
2. The query needs to NOT be I/O-bound. If it's I/O bound, then your
system is waiting for the data to come off disk, rather than to do
processing of that data.
yes and no on this one.
it is very possible to have a situation where the process
Each night we run over a 100,000 saved searches against PostgreSQL
9.0.x. These are all complex SELECTs using cube functions to perform a
geo-spatial search to help people find adoptable pets at shelters.
All of our machines in development in production have at least 2 cores
in them, and I'm
On 2/3/2011 9:08 AM, Mark Stosberg wrote:
Each night we run over a 100,000 saved searches against PostgreSQL
9.0.x. These are all complex SELECTs using cube functions to perform a
geo-spatial search to help people find adoptable pets at shelters.
All of our machines in development in
Time for my pet meme to wiggle out of its hole (next to Phil's, and a day
later). For PG to prosper in the future, it has to embrace the
multi-core/processor/SSD machine at the query level. It has to. And it has to
because the Big Boys already do so, to some extent, and they've realized that
On 02/03/2011 10:54 AM, Oleg Bartunov wrote:
Mark,
you could try gevel module to get structure of GIST index and look if
items distributed more or less homogenous (see different levels). You
can visualize index like http://www.sai.msu.su/~megera/wiki/Rtree_Index
Also, if your searches are
On Thu, Feb 3, 2011 at 4:57 PM, gnuo...@rcn.com wrote:
Time for my pet meme to wiggle out of its hole (next to Phil's, and a day
later). For PG to prosper in the future, it has to embrace the
multi-core/processor/SSD machine at the query level. It has to. And it has
to because the Big
On Thu, Feb 3, 2011 at 8:57 AM, gnuo...@rcn.com wrote:
Time for my pet meme to wiggle out of its hole (next to Phil's, and a day
later). For PG to prosper in the future, it has to embrace the
multi-core/processor/SSD machine at the query level. It has to. And
I'm pretty sure multi-core
Original message
Date: Thu, 3 Feb 2011 18:56:34 +0100
From: pgsql-performance-ow...@postgresql.org (on behalf of Aljoša Mohorović
aljosa.mohoro...@gmail.com)
Subject: Re: [PERFORM] getting the most of out multi-core systems for repeated
complex SELECT statements
To: gnuo...@rcn.com
Scott Marlowe wrote:
On Thu, Feb 3, 2011 at 8:57 AM, gnuo...@rcn.com wrote:
Time for my pet meme to wiggle out of its hole (next to Phil's, and a day
later). For PG to prosper in the future, it has to embrace the
multi-core/processor/SSD machine at the query level. It has to. And
On 02/03/2011 04:56 PM, Greg Smith wrote:
Scott Marlowe wrote:
On Thu, Feb 3, 2011 at 8:57 AM,gnuo...@rcn.com wrote:
Time for my pet meme to wiggle out of its hole (next to Phil's, and a day
later). For PG to prosper in the future, it has to embrace the
multi-core/processor/SSD machine at
Andy Colson wrote:
Cpu's wont get faster, but HD's and SSD's will. To have one database
connection, which runs one query, run fast, it's going to need
multi-core support.
My point was that situations where people need to run one query on one
database connection that aren't in fact limited
On Thu, Feb 3, 2011 at 9:00 PM, Greg Smith g...@2ndquadrant.com wrote:
Andy Colson wrote:
Cpu's wont get faster, but HD's and SSD's will. To have one database
connection, which runs one query, run fast, it's going to need multi-core
support.
My point was that situations where people need
On 02/03/2011 10:00 PM, Greg Smith wrote:
Andy Colson wrote:
Cpu's wont get faster, but HD's and SSD's will. To have one database
connection, which runs one query, run fast, it's going to need multi-core
support.
My point was that situations where people need to run one query on one
On Thu, Feb 3, 2011 at 9:19 PM, Andy Colson a...@squeakycode.net wrote:
On 02/03/2011 10:00 PM, Greg Smith wrote:
Andy Colson wrote:
Cpu's wont get faster, but HD's and SSD's will. To have one database
connection, which runs one query, run fast, it's going to need multi-core
support.
My
17 matches
Mail list logo
