Re: Fastest way to drop an index?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Phoenix Kiula <phoenix(dot)kiula(at)gmail(dot)com>
Cc: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, PG-General Mailing List <pgsql-general(at)postgresql(dot)org>
Subject: Re: Fastest way to drop an index?
Date: 2009-02-03 21:13:24
Message-ID: 15129.1233695604@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Phoenix Kiula <phoenix(dot)kiula(at)gmail(dot)com> writes:
> Index Scan using new_idx_testimonials_userid on testimonials
> (cost=0.00..157.78 rows=1 width=9) (actual time=8809.715..8809.715
> rows=0 loops=1)
> Index Cond: ((user_id)::text = 'superman'::text)
> Filter: ((title_encrypted)::text = 'b333dc1b0992cb8c70b58a418211389a'::text)
> Total runtime: 8809.750 ms

This is using the index to fetch the rows that match user_id = 'superman',
and then testing each fetched row to see if it has the desired value of
title_encrypted. The fact that hardly any rows pass the filter test
tells nearly nothing about how long this should be expected to run.
The rather high estimated cost suggests that the planner thinks there
are several dozen rows matching the index condition, and the actual
runtime suggests that there are actually hundred or thousands of 'em.
If so, your problem is that you need a different index. I'd bet on an
index on title_encrypted being more useful for this query than the one
on user_id; or you could experiment with a two-column index.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Grzegorz Jaśkiewicz 2009-02-03 21:17:11 what's the deal with 8.3.6 tagged, but not released yet ?
Previous Message Grzegorz Jaśkiewicz 2009-02-03 21:07:22 Re: C function question