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 th
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 generati
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 exten
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 onl
On Thu, Feb 3, 2011 at 9:19 PM, Andy Colson 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 p
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 database
On Thu, Feb 3, 2011 at 9: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
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 by
On 02/03/2011 04:56 PM, Greg Smith wrote:
Scott Marlowe wrote:
On Thu, Feb 3, 2011 at 8:57 AM, 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
Scott Marlowe wrote:
On Thu, Feb 3, 2011 at 8:57 AM, 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 sur
Original message
>Date: Thu, 3 Feb 2011 18:56:34 +0100
>From: pgsql-performance-ow...@postgresql.org (on behalf of Aljoša Mohorović
>)
>Subject: Re: [PERFORM] getting the most of out multi-core systems for repeated
>complex SELECT statements
>To: gnuo...@
On Thu, Feb 3, 2011 at 8:57 AM, 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 query processi
On Thu, Feb 3, 2011 at 4:57 PM, 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 Boys already
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
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 neighbourhood searches, them you could try knn,
l.org (on behalf of Andy Colson
>)
>Subject: Re: [PERFORM] getting the most of out multi-core systems for repeated
>complex SELECT statements
>To: Mark Stosberg
>Cc: pgsql-performance@postgresql.org
>
>On 2/3/2011 9:08 AM, Mark Stosberg wrote:
>>
>> Each night we
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 produc
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
18 matches
Mail list logo
