"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> If xact A is using a snapshot from before the commit of the index
> DROP, it shouldn't see anything done after the drop anyway. If
> it's using a snapshot from after the DROP, it won't see the index.
> xact B would only fail to update the index if it
I wrote:
> In the particular case at hand, a planner hook to make it ignore the
> index is a far better solution anyway...
Just as proof of concept, a quick-and-dirty version of this is attached.
It works in 8.3 and up. Sample (after compiling the .so):
regression=# load '/home/tgl/pgsql/planign
>>> On Wed, Feb 27, 2008 at 5:00 PM, in message <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
>> Out of curiosity, couldn't any transaction using a snapshot prior to
>> the commit of the DROP continue to use it (just like an uncommited
>>
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> Out of curiosity, couldn't any transaction using a snapshot prior to
> the commit of the DROP continue to use it (just like an uncommited
> DELETE of a row)? The transaction doing the DROP wouldn't maintain
> it for modifications, which is fine whethe
>>> On Tue, Feb 26, 2008 at 10:48 PM, in message <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> Er, later than what? Once the DROP is pending, other transactions can
> hardly safely use the index for lookups, and what should they do about
> insertions?
Out of curiosity, couldn't a
Jeff Davis <[EMAIL PROTECTED]> writes:
>>> begin;
>>> drop index abc_dx;
>>> select
>>> rollback;
> It may cause catalog bloat though, right?
Not in this particular case; AFAIR this will only result in catalog row
deletions, not updates. So when the deletions roll back, there's no
dead rows
On Tue, 2008-02-26 at 17:22 -0500, Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > "Scott Marlowe" <[EMAIL PROTECTED]> wrote:
> >> begin;
> >> drop index abc_dx;
> >> select
> >> rollback;
> >>
> >> and viola, your index is still there. note that there are likely some
> >
2008/2/27, Scott Marlowe <[EMAIL PROTECTED]>:
> On Tue, Feb 26, 2008 at 10:48 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > "Markus Bertheau" <[EMAIL PROTECTED]> writes:
> > > 2008/2/27, Tom Lane <[EMAIL PROTECTED]>:
> >
> > >> No, what makes you think that? The index won't change at all in the
"Markus Bertheau" <[EMAIL PROTECTED]> writes:
> On the other hand, if the only reason to have that feature is to plan
> and execute queries pretending that one index doesn't exist, then DROP
> INDEX DEFERRED is not the most straightforward syntax.
Yeah, I was just about to mention that 8.3 has a h
On Tue, Feb 26, 2008 at 10:48 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Markus Bertheau" <[EMAIL PROTECTED]> writes:
> > 2008/2/27, Tom Lane <[EMAIL PROTECTED]>:
>
> >> No, what makes you think that? The index won't change at all in the
> >> above example. The major problem is, as Scott says,
"Markus Bertheau" <[EMAIL PROTECTED]> writes:
> 2008/2/27, Tom Lane <[EMAIL PROTECTED]>:
>> No, what makes you think that? The index won't change at all in the
>> above example. The major problem is, as Scott says, that DROP INDEX
>> takes exclusive lock on the table so any other sessions will be
On Tue, Feb 26, 2008 at 8:48 PM, Markus Bertheau
<[EMAIL PROTECTED]> wrote:
> 2008/2/27, Tom Lane <[EMAIL PROTECTED]>:
>
>
> > "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > > "Scott Marlowe" <[EMAIL PROTECTED]> wrote:
> >
> > >> begin;
> > >> drop index abc_dx;
> > >> select
> >
2008/2/27, Tom Lane <[EMAIL PROTECTED]>:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > "Scott Marlowe" <[EMAIL PROTECTED]> wrote:
>
> >> begin;
> >> drop index abc_dx;
> >> select
> >> rollback;
> >>
> >> and viola, your index is still there. note that there are likely some
> >>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 26 Feb 2008 17:22:40 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > "Scott Marlowe" <[EMAIL PROTECTED]> wrote:
> >> begin;
> >> drop index abc_dx;
> >> select
> >> rollback;
> >>
> >> and vi
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> "Scott Marlowe" <[EMAIL PROTECTED]> wrote:
>> begin;
>> drop index abc_dx;
>> select
>> rollback;
>>
>> and viola, your index is still there. note that there are likely some
>> locking issues with this, so be careful with it in production. But
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 26 Feb 2008 14:57:51 -0600
"Scott Marlowe" <[EMAIL PROTECTED]> wrote:
> The brick to the head method would use set enable_indexscan = off;
> However, you can delete an index without actually deleting it like so:
>
> begin;
> drop index abc_
On Tue, Feb 26, 2008 at 2:46 PM, Peter Koczan <[EMAIL PROTECTED]> wrote:
> This might be a weird question...is there any way to disable a
> particular index without dropping it?
>
> There are a few queries I run where I'd like to test out the effects
> of having (and not having) different indexe
This might be a weird question...is there any way to disable a
particular index without dropping it?
There are a few queries I run where I'd like to test out the effects
of having (and not having) different indexes on particular query plans
and performance. I'd really prefer not to have to drop an
18 matches
Mail list logo
