On 4/27/2011 11:15 AM, Phoenix Kiula wrote:
Hi.
Just want to check why, in an UPDATE sql, the JOIN condition is not
making use of the index?
In both tables being joined, the column in question is in fact the
primary key!
Table structure and query below. All I want is to take values from a
smal
Phoenix Kiula writes:
> Just want to check why, in an UPDATE sql, the JOIN condition is not making
> use of the index?
> [ whole-table update done with a hash join ]
That's a perfectly good plan. Indexes typically help only when you want
to process just part of a table.
If you don't believe it,
On Mon, 13 Aug 2007, Scott Marlowe wrote:
We can look at how big your shared_buffers are, your work_mem, and a
few others in postgresql.conf.
That's going to be sort_mem, not work_mem, with 7.4
--
* Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD
-
Oh yeah, go read this:
http://www.westnet.com/~gsmith/content/postgresql/pg-5minute.htm
Note that you shouldn't set your shared buffers quite as high as in
that guide, since you're running 7.4 which isn't quite as good at
using shared_buffers
---(end of broadcast)
Oh, and you can use the sledge hammer of tuning by using the
set enable_xxx = off
settings for the planner. It's not a normal way to tune most queries,
but it certainly can let you know if the problem is using the index or
not.
psql mydb
\timing
select count(*) from table where field > 12345;
s
On 8/13/07, Ralph Smith <[EMAIL PROTECTED]> wrote:
>
>
>
> On Aug 13, 2007, at 4:39 PM, Scott Marlowe wrote:
>
> On 8/13/07, Ralph Smith <[EMAIL PROTECTED]> wrote:
> I'm confused. Shouldn't this index be used?
> (It's running on v7.4.7)
>
> airburst=> \d stats2
> Table "public.stats2"
On Aug 13, 2007, at 4:39 PM, Scott Marlowe wrote:
On 8/13/07, Ralph Smith <[EMAIL PROTECTED]> wrote:
I'm confused. Shouldn't this index be used?
(It's running on v7.4.7)
airburst=> \d stats2
Table "public.stats2"
Column | Type | Modifiers
---+---
On 8/13/07, Ralph Smith <[EMAIL PROTECTED]> wrote:
> I'm confused. Shouldn't this index be used?
> (It's running on v7.4.7)
>
> airburst=> \d stats2
> Table "public.stats2"
> Column | Type | Modifiers
> ---+---+---
> lab
Shane <[EMAIL PROTECTED]> writes:
> I am working with a simple table and query abut cannot seem
> to get it to use the index I have created.
> ...
> explain analyze select msgid from seen where msgtime < cast(now() - interval
> '6 months' as timestamp(0) without time zone);
As some other people a
On Wed, 2005-08-10 at 13:31 -0700, Shane wrote:
> On Wed, Aug 10, 2005 at 04:24:51PM -0400, Sven Willenberger wrote:
> > On Wed, 2005-08-10 at 12:58 -0700, Shane wrote:
> > > On Wed, Aug 10, 2005 at 03:31:27PM -0400, Sven Willenberger wrote:
> > > > Right off the bat (if I am interpreting the resul
On Wed, 2005-08-10 at 12:58 -0700, Shane wrote:
> On Wed, Aug 10, 2005 at 03:31:27PM -0400, Sven Willenberger wrote:
> > Right off the bat (if I am interpreting the results of your explain
> > analyze correctly) it looks like the planner is basing its decision to
> > seqscan as it thinks that it ne
On Wed, 2005-08-10 at 12:01 -0700, Shane wrote:
> Hello all,
>
> I am working with a simple table and query abut cannot seem
> to get it to use the index I have created. However, if I
> set enable_seqscan=false, the index is used and the query
> is much faster. I have tried a vacuum analyze but
On Wed, 2005-08-10 at 12:01 -0700, Shane wrote:
> Hello all,
>
> I am working with a simple table and query abut cannot seem
> to get it to use the index I have created. However, if I
> set enable_seqscan=false, the index is used and the query
> is much faster. I have tried a vacuum analyze but
On Tue, 15 Jun 2004 13:06:40 -0700, Shane Wegner
<[EMAIL PROTECTED]> wrote:
>The index I created reads:
>create index books_idx1 on books(publisher_id,place_id,illustrator_id,
>edition_id,type_id,category_id,binding_id,id);
This index is useless, drop it. Is there an index on books(id)?
>The oth
Waldo Nell <[EMAIL PROTECTED]> writes:
> I have a *huge* problem. I have a table with indexes on but the moment
> I have an OR in my SELECT query it seems to not use the appropriate
> index.
7.5 will be smarter about this, but in 7.4 and before you need to fool
with the column order of your i
Great! Many thanks.
Casting the type did the trick.
Even though it is somehow clear now, I don't see why the type is (can)
not (be) inferred from the field type.
--
Carlos G Mendioroz <[EMAIL PROTECTED]> LW7 EQI Argentina
---(end of broadcast)---
CREATE TABLE public.base (
nombre varchar(255),
calle varchar(255),
puerta int2,
resto varchar(255),
lid int2,
area varchar(4),
telefono varchar(10)
)
CREATE INDEX base_dir ON base USING btree (lid, calle, puerta);
And trying the following select:
select * from base where lid = 457
17 matches
Mail list logo
