On 13-5-2009 20:39 Scott Carey wrote:
Excellent! That is a pretty huge boost. I'm curious which aspects of this
new architecture helped the most. For Postgres, the following would seem
the most relevant:
1. Shared L3 cache per processors -- more efficient shared datastructure
access.
2.
-Original Message-
From: pgsql-performance-ow...@postgresql.org [mailto:pgsql-performance- A
much
better index to answer your query is (city_id, house_id, floor_id) -
then it can just look up straight away. Instead of the index returning
20 rows to check, it will return just
On Wed, 13 May 2009, Scott Carey wrote:
Can you do a quick and dirty memory bandwidth test? (assuming linux)
/sbin/hdparm -T /dev/sddevice
...its not a very accurate measurement, but its quick and highlights
relative hardware differences very easily.
I've found hdparm -T to be useful for
On Thu, 14 May 2009, Ow Mun Heng wrote:
Shouldn't BITMAP indexes come into play?
Does having one index w/ 3 parameters being better than 3 index w/ 3
different parameters be better for BITMAP index seeks?
I'll let someone correct me if I'm wrong, but using a single index that
exactly covers
-Original Message-
From: Matthew Wakeling [mailto:matt...@flymine.org]
On Thu, 14 May 2009, Ow Mun Heng wrote:
Shouldn't BITMAP indexes come into play?
Does having one index w/ 3 parameters being better than 3 index w/ 3
different parameters be better for BITMAP index seeks?
I'll
I was glad to find in 8.3.7 that pg was now smart enough to use an index
for a simple UNION ALL. But unfortunately, it's not quite there yet for
our use case.
Consider the following dummy tables:
create table foo (id serial primary key, val int not null);
create table bar (id serial primary
Brad Jorsch program...@protech1inc.com writes:
But if I add a constant-valued column to indicate which branch of the
union each result came from:
explain analyze select * from baz join (
select id, val, 'foo'::text as source from foo
union all
select id, val, 'bar'::text as source
On Thu, May 14, 2009 at 4:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Brad Jorsch program...@protech1inc.com writes:
But if I add a constant-valued column to indicate which branch of the
union each result came from:
explain analyze select * from baz join (
select id, val, 'foo'::text as
Mathieu De Zutter math...@dezutter.org writes:
On Thu, May 14, 2009 at 4:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It's an ancient and fundamental limitation that is fixed in 8.4.
Do not expect to see it fixed in 8.3.x.
Does this also apply to the case of a join on an inherited table ?
On 5/13/09 11:52 PM, Greg Smith gsm...@gregsmith.com wrote:
On Wed, 13 May 2009, Scott Carey wrote:
Can you do a quick and dirty memory bandwidth test? (assuming linux)
/sbin/hdparm -T /dev/sddevice
...its not a very accurate measurement, but its quick and highlights
relative hardware
On Tue, 2009-05-12 at 14:28 +0200, Dimitri wrote:
As problem I'm considering a scalability issue on Read-Only workload -
only selects, no disk access, and if on move from 8 to 16 cores we
gain near 100%, on move from 16 to 32 cores it's only 10%...
Dimitri,
Will you be re-running the
On 5/13/09 11:21 PM, Arjen van der Meijden acmmail...@tweakers.net
wrote:
On 13-5-2009 20:39 Scott Carey wrote:
Excellent! That is a pretty huge boost. I'm curious which aspects of this
new architecture helped the most. For Postgres, the following would seem
the most relevant:
1.
It's absolutely great!
it'll not help here because a think time is 0.
but for any kind of solution with a spooler it's a must to try!
Rgds,
-Dimitri
On 5/13/09, Dimitri Fontaine dfonta...@hi-media.com wrote:
Hi,
Le 13 mai 09 à 18:42, Scott Carey a écrit :
will not help, as each client is
Hi Scott,
let me now finish my report and regroup all data together, and then
we'll continue discussion as it'll come more in debug/profile phase..
- I'll be not polite from my part to send some tons of attachments to
the mail list :-)
Rgds,
-Dimitri
On 5/13/09, Scott Carey
On Thu, May 14, 2009 at 9:08 PM, Craig James craig_ja...@emolecules.com wrote:
I disagree -- it's a glaring error. More optimized or better optimized
are perfectly good, and correct, phrases. Why not use them? Every time I
read more optimal, I am embarrassed for the person who is showing
David Wilson wrote:
On Tue, May 12, 2009 at 5:53 PM, Angel Alvarez cl...@uah.es wrote:
we suffer a 'more optimal' superlative missuse
there is not so 'more optimal' thing but a simple 'better' thing.
im not native english speaker but i think it still applies.
Well this a superlative list
16 matches
Mail list logo
