Tsuraan,
"Select count(*) from bigtable" is testing your disk drive speed up till
about 300MB/s, after which it is CPU limited in Postgres.
My guess is that your system has a very slow I/O configuration, either due
to faulty driver/hardware or the configuration.
The first thing you should do is
* tsuraan <[EMAIL PROTECTED]> [061216 18:26]:
> I'm writing a webmail-type application that is meant to be used in a
> corporate environment. The core of my system is a Postgres database
> that is used as a message header cache. The two (relevant) tables
> being used are pasted into the end of th
Le samedi 16 décembre 2006 18:32, Steinar H. Gunderson a écrit :
> Instead, try real queries on real data,
> and post here if some are too slow for you.
To quickly find out a subset of slow queries on your production system, you
can use the pgfouine tool:
http://pgfouine.projects.postgresql.org
Ireneusz Pluta <[EMAIL PROTECTED]> writes:
> Can you show what you get from:
> EXPLAIN SELECT * FROM data WHERE name LIKE 'a%'
Won't help. Exact equality of the WHERE condition is useful for
partial-index cases, because there the planner needs to prove that
the WHERE condition implies the index p
Ireneusz Pluta wrote:
> Can you show what you get from:
> EXPLAIN SELECT * FROM data WHERE name LIKE 'a%'
>
> ?
>
> Irek.
I get:
QUERY PLAN
Result (cost=0.00..24.42 rows=8 width=48)
-> A
jamcito napisał(a):
/*/
SET constraint_exclusion=on;
SET
SHOW constraint_exclusion;
constraint_exclusion
--
on
(1 row)
EXPLAIN SELECT * FROM data WHERE name = 'aaa';
QUERY PLAN
-
Tom Lane wrote:
>> CREATE TABLE data_a (CHECK (name LIKE varchar 'a%')
>> ) INHERITS (data);
>> --
>> CREATE TABLE data_b (CHECK (name LIKE varchar 'b%')
>> ) INHERITS (data);
>
> That's not going to work because the planner is unable to prove anything
> about the behavior of LIKE --- there is not
Unqualified SELECT COUNT(*) FROM foo is one of the most expensive operations
you can do on your system, since the visibility information has to be
checked
on disk for each row. Instead, try real queries on real data, and post here
if some are too slow for you.
Ok, that's a bad example. I'm lear
On Sat, Dec 16, 2006 at 10:53:21AM -0500, Ron wrote:
The most important "gain" IMO is Knowledge, and I'd say there is
still more to learn and/or verify IMHO. YMMV.
Well, I think there are other areas where I can spend my time where
potential gains are more likely. YMMV (although, I note, you d
On Sat, Dec 16, 2006 at 11:26:02AM -0600, tsuraan wrote:
> Even an operation like "select count(*) from messages" can take minutes,
> with a totally idle system. Postgres seems to be the most scalable Free
> database out there, so I must be doing something wrong.
Unqualified SELECT COUNT(*) FROM
I'm writing a webmail-type application that is meant to be used in a
corporate environment. The core of my system is a Postgres database
that is used as a message header cache. The two (relevant) tables
being used are pasted into the end of this message. My problem is
that, as the messages tabl
On Sat, Dec 16, 2006 at 10:53:21AM -0500, Ron wrote:
> AFAICT, no one has stated there would be a "blow-your-socks-off
> dramatic performance improvement" for pg due to compilation
> options. Just that there might be some, and there might be some that
> are arch specific.
FWIW, the original cl
At 07:06 PM 12/15/2006, Michael Stone wrote:
On Fri, Dec 15, 2006 at 12:24:46PM -0500, Ron wrote:
ATM, the most we can say is that in a number of systems with modest
physical IO subsystems
So I reran it on a 3.2GHz xeon with 6G RAM off a ramdisk; I/O ain't
the bottleneck on that one. Results
jamcito <[EMAIL PROTECTED]> writes:
> I am trying to make partitions:
> CREATE TABLE data_a (CHECK (name LIKE varchar 'a%')
> ) INHERITS (data);
> --
> CREATE TABLE data_b (CHECK (name LIKE varchar 'b%')
> ) INHERITS (data);
That's not going to work because the planner is unable to prove anything
Hello,
I am trying to make partitions:
CREATE SEQUENCE data_seq;
CREATE TABLE data (
identyf bigint,
namevarchar,
added timestamp default now()
);
/*/
CREATE TABLE data_a (CHECK (name LIKE varchar 'a%')
) INHERITS (data);
-
Alexander Staubo wrote:
On Dec 15, 2006, at 17:53 , Ron wrote:
At 09:50 AM 12/15/2006, Greg Smith wrote:
On Fri, 15 Dec 2006, Merlin Moncure wrote:
The slower is probably due to the unroll loops switch which can
actually hurt code due to the larger footprint (less cache coherency).
The
On 16-12-2006 4:24 Jeff Frost wrote:
We can add more RAM and drives for testing purposes. Can someone
suggest what benchmarks with what settings would be desirable to see how
this system performs. I don't believe I've seen any postgres benchmarks
done on a quad xeon yet.
We've done our "sta
17 matches
Mail list logo
