e.
Any clues if there's any parameter or bug causing that?
Gan (for Amgad)
--
+--------+
| Seum-Lim GAN email : [EMAIL PROTECTED] |
| Lucent Technologies|
| 2000 N. Naperville Road, 6B-403F
don't intend to use
the full option since it locks the table.
I have 7.3.3 running in Solaris 9.
Any recommendation ?
Thanks.
Gan
--
+----+
| Seum-Lim GAN email : [EMAIL PROTECTED] |
| Lucent Technol
besides shutting down to
do full vacuum ?
Peter Child also mentions there is indexing bugs.
Is this fixed in 7.3.4 ? I did notice after the database
grew in disk usage, its performance greatly decreases !
Gan
Seum-Lim Gan wrote:
I have a table that keeps being updated and noticed
that after a few
--
++
| Seum-Lim GAN email : [EMAIL PROTECTED] |
| Lucent Technologies|
| 2000 N. Naperville Road, 6B-403F tel : (630)-713-6665 |
| Naperville, IL 60566, USA.fax : (630)-713-7272 |
| web
7.4beta4 ?
No, it should be. Please post your max_fsm_pages setting, and the output of a
sample VACUUM VERBOSE ANALYZE. You probably don't have your FSM set right.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 7
were 0 unused item pointers.
0 pages are entirely empty.
CPU 1.95s/1.99u sec elapsed 26.95 sec.
INFO: analyzing "craft.dsperf_rda_or_key"
INFO: "hello_rda_or_key": 30909 pages, 3000 rows sampled, 93292
estimated total rows
VACUUM
Gan
At 10:21 pm -0400 2003/10/18, Tom Lane wrote
this going to post a problem if we do not have
the thread-safety option during configure ?
Thanks.
Gan
At 1:48 am -0400 2003/10/19, Tom Lane wrote:
Seum-Lim Gan <[EMAIL PROTECTED]> writes:
INFO: vacuuming "craft.dsperf_rda_or_key"
INFO: index "hello242_1105" now c
42u sec elapsed 26.65 sec.
INFO: analyzing "scncraft.dsperf_rda_or_key"
INFO: "dsperf_rda_or_key": 35315 pages, 3000 rows sampled, 106627
estimated total rows
VACUUM
Sleep 60 seconds
.
.
.
Thanks.
Gan
At 11:47 am -0400 2003/10/19, Tom Lane wrote:
Seum-Lim Gan <[EMAIL PROTECTED
growing afterwards. Vacuum/vacuum analyze did not help.
In all the update testing, vacuum analyze was done every 1 minute.
Tom, something caught your attention the last time.
Any insight so far ? Is it a bug ?
Thanks.
Gan
Tom Lane wrote:
Seum-Lim Gan <[EMAIL PROTECTED]> writes:
vacuum v
Hi Tom, Josh,
We tried one more thing: with the table not being updated
at all and we did vacuum. Each time a vacuum is done,
the index file becomes bigger.
This is probably what is contributing to the index file
growing as well.
Thanks.
Gan
At 11:04 am -0500 2003/10/20, Seum-Lim Gan wrote:
Hi
10/20, Tom Lane wrote:
Seum-Lim Gan <[EMAIL PROTECTED]> writes:
We tried one more thing: with the table not being updated
at all and we did vacuum. Each time a vacuum is done,
the index file becomes bigger.
It is not possible for plain vacuum to make the index bigger.
VACUUM FULL possibly
--
++
| Seum-Lim GAN email : [EMAIL PROTECTED] |
| Lucent Technologies|
| 2000 N. Naperville Road, 6B-403F tel : (630)-713-6665 |
| Naperville, IL 60566, USA.fax : (630)-713-7272 |
| web
12 matches
Mail list logo