Hi Duan,
As others have said, you should probably attempt to run pg_dump to export your
database. If that doesn't work, consider restoring from backup. If the dump
does work, you can create a clean PGDATA directory (using initdb like when you
setup your original installation), and create a
Alvaro Herrera wrote:
Move the old clog files back where they were, and run VACUUM FREEZE in
all your databases. That should clean up all the old pg_clog files, if
you're really that desperate.
Has anyone actually seen a CLOG file get removed under 8.2 or 8.3? How about
8.1?
I'm probably
Tom Lane [EMAIL PROTECTED] writes:
Matt Smiley [EMAIL PROTECTED] writes:
So an Index Scan is always going to have a higher cost estimate than
an equivalent Seq Scan returning the same result rows (unless
random_page_cost is 1). That's why I think the planner is always
Tom Lane [EMAIL PROTECTED] writes:
I'm not sure offhand whether the existing correlation stats would be of use
for
it, or whether we'd have to get ANALYZE to gather additional data.
Please forgive the tangent, but would it be practical to add support for
gathering statistics on an arbitrary
Hi David,
Early in this thread, Pavel suggested:
you should partial index
create index foo(b) on mytable where a is null;
Rather, you might try the opposite partial index (where a is NOT null) as a
replacement for the original unqualified index on column A. This new index
will be ignored
Hi David,
Thanks for your feedback! I'm rather a newbie at this, and I do appreciate the
critique.
First, let me correct myself: The formulas for the risk of loosing data when
you loose 2 and 3 disks shouldn't have included the first term (g/n). I'll
give the corrected formulas and tables
Hi Dimitri,
First of all, thanks again for the great feedback!
Yes, my I/O load is mostly read operations. There are some bulk writes done in
the background periodically throughout the day, but these are not as
time-sensitive. I'll have to do some testing to find the best balance of read
dispatches only
1 logical I/O request at a time.
Dimitri [EMAIL PROTECTED] 03/23/07 2:28 AM
On Friday 23 March 2007 03:20, Matt Smiley wrote:
My company is purchasing a Sunfire x4500 to run our most I/O-bound
databases, and I'd like to get some advice on configuration and tuning.
We're currently
My company is purchasing a Sunfire x4500 to run our most I/O-bound databases,
and I'd like to get some advice on configuration and tuning. We're currently
looking at:
- Solaris 10 + zfs + RAID Z
- CentOS 4 + xfs + RAID 10
- CentOS 4 + ext3 + RAID 10
but we're open to other suggestions.
From
