Christopher Browne kirjutas K, 01.10.2003 kell 19:21:
The FS-related result appeared surprising, as the stories I had
heard suggested that JFS hadn't been particularly heavily tuned on
Linux, whereas XFS was supposed to be the speed demon.
Gentoo linux recommends XFS only for SAN+fibre
Unfortunately, while there are companies hawking SSDs, they are in the
you'll have to talk to our salescritter for pricing category, which
means that they must be ferociously expensive. :-(.
the cheapest I found was the one with external backup power was ~1.8k$
for 2GB PCI device
Andrew Sullivan wrote:
Yes. If and only if you have a battery-backed cache. I know of no
IDE drives that have that, but there's nothing about the spec which
makes it impossible.
http://www.ussg.iu.edu/hypermail/linux/kernel/0103.0/1084.html
Relevant section:
quote
Maybe that is why there is a
On Wed, 2003-10-01 at 10:13, Jason Hihn wrote:
We have an opportunity to purchase a new, top-notch database server. I am
wondering what kind of hardware is recommended? We're on Linux platforms and
kernels though. I remember a comment from Tom about how he was spending a
lot of time debugging
RJ == Richard Jones [EMAIL PROTECTED] writes:
RJ Hi, i'm on the verge of buying a MegaRAID SCSI 320-2 raid controller.
RJ I need it to build a db server using 4x ultra320 scsi disks
RJ i'm thinking raid 1+0 but will try with raid5 too and compare
No specific tips on that particular RAID, but in
I ran VACUUM FULL ANALYZE yesterday and the re-ran the query with
EXPLAIN ANALYZE.
I got the same query plan and execution time.
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2003 4:20 PM
To: Oleg Lebedev
Cc: Josh Berkus; scott.marlowe; [EMAIL
Hi folks.
What's wrong with planner that executes my query in function?:
(i mean no explanation but runtime)
tele=# EXPLAIN analyze select calc_total(6916799, 1062363600, 1064955599);
QUERY PLAN
As Scott recommended, I did the following:
# set enable_nestloop = false;
# vacuum full analyze;
After this I re-ran the query and its execution time went down from 2
hours to 2 minutes. I attached the new query plan to this posting.
Is there any way to optimize it even further?
What should I do
Have you tried increasing the statistics target for those columns that are
getting bad estimates yet and then turning back on enable_nestloop and
rerunning analyze and seeing how the query does?
The idea being to try and get a good enough estimate of your statistics so
the planner stops
On Thu, 2003-10-02 at 14:30, Rong Wu wrote:
Hi,
I have a select like this:
SELECT MAX(transactionid) FROM cbntransaction WHERE transactiontypeid=0;
For various reasons (primarily MVCC and the ability to make custom
aggregates making it difficult) MAX() is not optimized in this fashion.
I was testing to get some idea of how to speed up the speed of pgbench
with IDE drives and the write caching turned off in Linux (i.e. hdparm -W0
/dev/hdx).
The only parameter that seems to make a noticeable difference was setting
wal_sync_method = open_sync. With it set to either fsync, or
On Thu, Oct 02, 2003 at 12:46:45 -0700,
Dror Matalon [EMAIL PROTECTED] wrote:
Please keep replies copied to the list.
When would it happen that a tuple be invisible to the current
transaction? Are we talking about permissions?
They could be tuples that were changed by a transaction that
On Thu, 2 Oct 2003, Oleg Lebedev wrote:
I was trying to get the pg_stats information to Josh and decided to
recreate the indexes on all my tables. After that I ran vacuum full
analyze, re-enabled nestloop and ran explain analyze on the query. It
ran in about 2 minutes.
I attached the new
Christopher Browne [EMAIL PROTECTED] writes:
It would be very hairy to implement it correctly, and all this would
cover is the single case of SELECT COUNT(*) FROM SOME_TABLE;
If you had a single WHERE clause attached, you would have to revert to
walking through the tuples looking for the
Oleg,
I have another question. How do I optimize my indexes for the query that
contains a lot of ORed blocks, each of which contains a bunch of ANDed
expressions? The structure of each ORed block is the same except the
right-hand-side values vary.
Given the example, I'd do a multicolumn
15 matches
Mail list logo
