David Wilson wrote:
On Tue, May 12, 2009 at 5:53 PM, Angel Alvarez 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 so all of you
On Thu, May 14, 2009 at 9:08 PM, Craig James 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 his/her
> ignorance
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 wrote:
>
> On 5/13/0
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 wrote:
> Hi,
>
> Le 13 mai 09 à 18:42, Scott Carey a écrit :
>>> will not help, as each client is *not* disconnecting/
Folks, sorry, I'm outpassed little bit by the events :-))
I've finished tests with PREPARE/EXECUTE - it's much faster of course,
and the max TSP is 15.000 now on 24 cores! - I've done various tests
to see where is the limit bottleneck may be present - it's more likely
something timer or interrupt
On 5/13/09 11:21 PM, "Arjen van der Meijden"
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. Shared L3 cache pe
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 Read
On 5/13/09 11:52 PM, "Greg Smith" 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/sd
>>
>> ...its not a very accurate measurement, but its quick and highlights
>> relative hardware difference
Mathieu De Zutter writes:
> On Thu, May 14, 2009 at 4:52 PM, Tom Lane 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 ?
> example: http://archives.postgresql.
On Thu, May 14, 2009 at 4:52 PM, Tom Lane wrote:
> "Brad Jorsch" 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
>> s
"Brad Jorsch" 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 from bar
> ) as foob
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 ke
-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?
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 y
14 matches
Mail list logo
