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
