On Fri, 4 May 2007, Michael Stone wrote:
P4 2.4GHz 107ms
Xeon 3GHz 100ms
Opteron 275 65ms
Athlon X2 4600 61ms
PIII 1GHz 265ms
Opteron 250 39ms
something seems inconsistent here.
I don't see what you mean. The PIII results are exactly what I'd expect,
and I wouldn'
Josh Berkus schrieb:
> Sebastian,
>
>
>> Before inventing a hyper tool, we might consider to provide 3-5 example
>> szenarios for common hardware configurations. This consumes less time
>> and be discussed and defined in a couple of days. This is of course not
>> the correct option for a brandn
Sebastian,
> Before inventing a hyper tool, we might consider to provide 3-5 example
> szenarios for common hardware configurations. This consumes less time
> and be discussed and defined in a couple of days. This is of course not
> the correct option for a brandnew 20 spindle Sata 10.000 Raid 10
On 5/4/07, Scott Marlowe <[EMAIL PROTECTED]> wrote:
On Thu, 2007-05-03 at 21:37, Merlin Moncure wrote:
> On 5/3/07, Fei Liu <[EMAIL PROTECTED]> wrote:
> > Hello, Andreas, I too am having exactly the same issue as you do.
> > Comparing my partitioned and plain table performance, I've found that
>
[EMAIL PROTECTED] schrieb:
> On Tue, 1 May 2007, Carlos Moreno wrote:
>
>>> large problem from a slog perspective; there is no standard way even
>>> within Linux to describe CPUs, for example. Collecting available disk
>>> space information is even worse. So I'd like some help on this
>>> port
At 16:26 04/05/2007, you wrote:
Paul Smith wrote:
Why doesn't it use the other index? If use 'set enable_seqscan=0'
then it does.
Just a guess, but is the table clustered on column a? Maybe not
explicitly, but was it loaded from data that was sorted by a?
I wouldn't have thought so - a is p
Paul Smith <[EMAIL PROTECTED]> writes:
> If I do
> EXPLAIN SELECT * FROM x ORDER BY a;
> it says
> Index Scan using y on x (cost=0.00..2903824.15 rows=1508057 width=152)
> That's what I'd expect
> However, if I do
> EXPLAIN SELECT * FROM x ORDER BY b;
> it says
> Sort (cost=711557.34..715327.
Paul Smith wrote:
Why doesn't it use the other index? If use 'set enable_seqscan=0' then
it does.
Just a guess, but is the table clustered on column a? Maybe not
explicitly, but was it loaded from data that was sorted by a?
Analyzer calculates the correlation between physical order and each
On Thu, 2007-05-03 at 21:37, Merlin Moncure wrote:
> On 5/3/07, Fei Liu <[EMAIL PROTECTED]> wrote:
> > Hello, Andreas, I too am having exactly the same issue as you do.
> > Comparing my partitioned and plain table performance, I've found that
> > the plain tables perform about 25% faster than parti
This is in Postgres 8.1.5
I have a table like
CREATE TABLE x (a VARCHAR, b VARCHAR, c VARCHAR);
CREATE INDEX y on x(a);
CREATE INDEX z on x(b);
There are over a million rows in 'x'. Neither a nor b are unique.
There are probably about 20 or so distinct values of a and 30 or so
distinct values
On Fri, May 04, 2007 at 12:53:55AM -0400, Greg Smith wrote:
It's also completely inappropriate for any environment I work in, because
there really is no thought of security whatsoever in the whole thing.
That makes it sound more like snmp, not less. :-)
Mike Stone
---
On Fri, May 04, 2007 at 12:33:29AM -0400, Greg Smith wrote:
-bash-3.00$ psql
postgres=# \timing
Timing is on.
postgres=# select count(*) from generate_series(1,10,1);
count
10
(1 row)
Time: 106.535 ms
There you go, a completely cross-platform answer. You should run the
stat
12 matches
Mail list logo
