Skip site navigation (1) Skip section navigation (2)

Re: indexes on functions and create or replace function

From: "Matthew Dennis" <mdennis(at)merfer(dot)net>
To: PGSQL <pgsql-general(at)postgresql(dot)org>
Subject: Re: indexes on functions and create or replace function
Date: 2008-08-30 17:27:32
Message-ID: e94d85500808301027i6af787fbkb4548295258a9c00@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-general
On Thu, Aug 28, 2008 at 7:45 PM, Matthew Dennis <mdennis(at)merfer(dot)net> wrote:

> Another question though.  Since I could potentially start transaction, drop
> indexes/checks, replace function, create indexes/checks, commit tranasaction
> could I deal with the case of the constant folding into the cached plan by
> flushing the entire cache in the same transaction?  Is cache flushing
> transactional?  The cases I have for this are infrequent in time and the
> overhead of reindexing things, rechecking checks/unique indexes already
> dwarf the performance lost to flushing the cache.
>
> On a related note, if I had a maintenence window where I can shutdown all
> DB access, make the referenced changes to the
> functions/indexes/caches/checks and restart PG - in your opinion, are there
> other likely problems to changing an immutable function under those
> circumstances, or should that be pretty safe?  In other words, I have a
> function that has indexes on it that does the wrong thing - what do I do to
> replace it?
>


In the thread below, we kind of got side tracked on some other stuff and I
never got an answer to the questions above.  Does anyone have any
insight/suggestions about the best way to replace a function that is used by
an index?

http://groups.google.com/group/pgsql.general/browse_thread/thread/92289ef0c2f5a109/8f96fb24bdd668e8

In response to

pgsql-general by date

Next:From: Albretch MuellerDate: 2008-08-30 17:33:24
Subject: Re: ERROR: relation . . . does not exist
Previous:From: Tom LaneDate: 2008-08-30 17:05:01
Subject: Re: DUPS in tables columns ERROR: column ". . . " does not exist

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group