),
name VARCHAR
port INTEGER,
--other data
);
It would probably help to have an index on that column for all three
tables, then I would wager using joins will be the speed winner.
-
Frank Wiles [EMAIL PROTECTED]
http://www.wiles.org
for the project,
the more the better. I'd say 2-4GB is the minimum. And RAID-5 isn't
very good for database work in general, you'll get better performance
from RAID 1+0.
-
Frank Wiles [EMAIL PROTECTED]
http://www.wiles.org
by PostgreSQL, nor does it reserve kernel disk cache; it is used
only for estimation purposes.
This is a hint to the optimizer about how much of the database may
be in the OS level cache.
-
Frank Wiles [EMAIL PROTECTED]
http://www.wiles.org
.
-
Frank Wiles [EMAIL PROTECTED]
http://www.wiles.org
-
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so
threads dating back 2000. A lot of things have improved with
PostgreSQL and hopefully the support for multiple cpu or dual cores is
already provided.
Yes PostgreSQL can take advantage of multiple CPUs and core, has been
able to for quite some time.
-
Frank
differences? Does the old server
have fast SCSI disk and the new box SATA? Or the old server was
on a RAID volume and the new one isn't, etc... those are the sort
of hardware differences that are important in this particular
case.
-
Frank Wiles [EMAIL
together multiple backend servers,
it also functions well as just a connection pooling device with
only one backend.
-
Frank Wiles [EMAIL PROTECTED]
http://www.wiles.org
-
---(end of broadcast
On Tue, 17 Jan 2006 16:12:59 -0500
[EMAIL PROTECTED] wrote:
In the mean time, I successfully use LIMIT and OFFSET without such an
optimization, and things have been fine for me.
Same here.
-
Frank Wiles [EMAIL PROTECTED]
http://www.wiles.org
://revsys.com/blog/archive/9, where I used a very simple
materialized view to achieve the performance I needed. It has links
to the relevant documentation you'll need however to build triggers
for a more complex situation.
Hope this helps!
-
Frank Wiles
configuration
values.
-
Frank Wiles [EMAIL PROTECTED]
http://www.wiles.org
-
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire
on report.id_order ? Try creating an index for
it if not and run a vacuum analyze on the table to see if it gets
rid of the sequence scan in the plan.
-
Frank Wiles [EMAIL PROTECTED]
http://www.wiles.org
http://www.powerpostgresql.com/PerfList
Hope these help!
-
Frank Wiles [EMAIL PROTECTED]
http://www.wiles.org
-
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
is raw speed.
However, that has to be balanced, from an overall perspective, with
the nice single point of ordering/contact/support/warranty of the
one vendor. It's a tough call.
-
Frank Wiles [EMAIL PROTECTED]
http://www.wiles.org
.
-
Frank Wiles [EMAIL PROTECTED]
http://www.wiles.org
-
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
extra performance,
but will probably not entirely solve your problem.
-
Frank Wiles [EMAIL PROTECTED]
http://www.wiles.org
-
---(end of broadcast)---
TIP 3: Have you checked our
notice slow queries real fast on such a box.
I know several people who use this development method. It can
sometimes lead to premature optimizations, but overall I think it is
a great way to work.
-
Frank Wiles [EMAIL PROTECTED]
http://www.wiles.org
On Wed, 9 Nov 2005 21:43:33 -0300
Alvaro Herrera [EMAIL PROTECTED] wrote:
Frank Wiles wrote:
Obviously there are systems/datasets/quantities where this won't
always work out best, but for the majority of systems out there
complicating your schema, maxing your hardware
there
complicating your schema, maxing your hardware, and THEN tuning
is IMHO the wrong approach.
-
Frank Wiles [EMAIL PROTECTED]
http://www.wiles.org
-
---(end of broadcast
efforts.
-
Frank Wiles [EMAIL PROTECTED]
http://www.wiles.org
-
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
increasing those configuration values and doing vacuums more
often.
If you should also explore upgrading to the latest 8.0 as you will
no doubt see noticeable speed improvements.
-
Frank Wiles [EMAIL PROTECTED]
http://www.wiles.org
this type of application is fairly trivial to write
in most scripting or higher level languages.
-
Frank Wiles [EMAIL PROTECTED]
http://www.wiles.org
-
---(end of broadcast
memory always helps out. Since you say these
queries are mostly on not-often-used data I would lean toward more
disks in your SCSI RAID-1 setup than maxing out available RAM based
on the size of your database.
-
Frank Wiles [EMAIL PROTECTED]
http
won't make up your speed difference.
-
Frank Wiles [EMAIL PROTECTED]
http://www.wiles.org
-
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http
that section.
-
Frank Wiles [EMAIL PROTECTED]
http://www.wiles.org
-
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
.
The article can be found here:
http://www.revsys.com/writings/postgresql-performance.html
Thanks!
-
Frank Wiles [EMAIL PROTECTED]
http://www.wiles.org
-
---(end of broadcast
. Thanks again for the
feedback.
-
Frank Wiles [EMAIL PROTECTED]
http://www.wiles.org
-
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
because you're not limiting the query in
the FROM clause. No point in using an index when you're asking for
the entire table. :)
-
Frank Wiles [EMAIL PROTECTED]
http://www.wiles.org
-
---(end
.
-
Frank Wiles [EMAIL PROTECTED]
http://www.wiles.org
-
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
the major resource intensive
queries on the database and time it. Tweak a PostgreSQL parameter
and re-run, wash, rinse, repeat until I get what I believe is the
best performance I can.
-
Frank Wiles [EMAIL PROTECTED]
http://www.wiles.org
worse after it was normalized. In fact, I can't even think of a
situation where it could!
-
Frank Wiles [EMAIL PROTECTED]
http://www.wiles.org
-
---(end of broadcast)---
TIP 3
the best DBA in the world.
I ended up having to push about 20% of the deep call details into
flat files and surprisingly enough it was faster to grep the flat
files than use the database, because as was previously mentioned
all of the joins.
-
Frank
On Fri, 17 Dec 2004 23:37:37 -0500
Tom Lane [EMAIL PROTECTED] wrote:
Frank Wiles [EMAIL PROTECTED] writes:
I've also seen a huge difference between select count(*) and
select count(1) in older versions,
That must have been before my time, ie, pre-6.4 or so. There is
certainly zero
the entire table on disk
is. I've also seen a huge difference between select count(*) and
select count(1) in older versions, haven't tried it on a recent
version however.
-
Frank Wiles [EMAIL PROTECTED]
http://www.wiles.org
space. You might also
want to adjust your free space map so that you don't have to do FULL
vacuums as often ( or at all ). It is controlled by max_fsm_pages
and max_fsm_relations.
-
Frank Wiles [EMAIL PROTECTED]
http://www.wiles.org
a matter of trial an error.
With my databases, I can afford to do VACUUM FULLs fairly often
so I typically don't need to increase my fsm values.
-
Frank Wiles [EMAIL PROTECTED]
http://www.wiles.org
badly ( PERC cards vs say a Mylex card ).
I think it's more of a system design issue ( wrt Linux use ) rather
than a quality issue.
-
Frank Wiles [EMAIL PROTECTED]
http://www.wiles.org
-
---(end
36 matches
Mail list logo
