Hi,
Thanks, i fix the problem, it was the linux configuration.
Ahora podés usar Yahoo! Messenger desde tu celular. Aprendé cómo hacerlo en Yahoo!
Móvil: http://ar.mobile.yahoo.com/sms.html
---(end of broadcast)---
TIP 2: you can get off all lis
>
>I have performance problems with a huge database
> (there a 2 tables with 40 millions of records) and
> many users doing updates and queries on it. I 've
> perform severals VACUMM on the database with poor
> results.
>Each table have an unique index and I added other
> indexes to improve
At 09:56 AM 12/12/2002 -0300, Héctor Iturre wrote:
I 've
perform severals VACUMM on the database with poor
results.
Have you done an ANALYZE?
Which version of PG are you using?
Can you send output from VACUUM VERBOSE ?
Philip
Hi,
I have performance problems with a huge database
(there a 2 tables with 40 millions of records) and
many users doing updates and queries on it. I 've
perform severals VACUMM on the database with poor
results.
Each table have an unique index and I added other
indexes to improve the perfor
Tom,
> Kinda hard to believe; even if the old indexes were still around,
> they
> wouldn't be considered to apply to the new table. I think the
> problem
> is something else. Can you provide a reproducible example of what
> you're seeing?
Wish I could; it only seems to happen on the production
Tom,
> I don't believe a single word of that explanation ... whatever is
> going
> on here, that ain't it. A new table is going to have a new OID, and
> so will its indexes; there is no way that Postgres will confuse it
> with
> the old one, even if bits of the old one were still hanging around
"Josh Berkus" <[EMAIL PROTECTED]> writes:
> This is on 7.1.2 (SuSE 7.2, ReiserFS, PG built from source). Explicitly
> dropping the indexes before dropping the tables seems to have solved the
> problem. My guess, without understanding the guts of the thing at all,
> is that the transactional natu
"Josh Berkus" <[EMAIL PROTECTED]> writes:
> 1. INDEXES: I discovered, the hard way, a peculiar problem. If you drop
> and re-create a table within the same transaction (in a function, for
> example) the indexes do not get dropped completely.
Kinda hard to believe; even if the old indexes were st
Who is this?
- Original Message -
From: Josh Berkus <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, October 17, 2001 8:59 AM
Subject: [SQL] Performance problems - Indexes and VACUUM
> Tom, Folks:
>
> I am having a rather interesting time getting
Tom, Folks:
I am having a rather interesting time getting performance out of my
database. I'd really appreciate some feedback from the list on this.
As you may recall, I've gotten around Postgres' lack of rowset-returning
stored procedures by constructing "pointer tables" which simply hold
lis
10 matches
Mail list logo
