On Wed, Apr 9, 2008 at 11:41 AM, PFC <[EMAIL PROTECTED]> wrote:
>In order to use the index, you could rewrite it as something like :
>a.calldate >= '2008-04-09' AND a.calldate < ('2008-04-09'::DATE + '1
> DAY'::INTERVAL)
>This is a RANGE query (just like BETWEEN) which is in
Well, this table has a primary key index on first column called acctid
which is an integer; instead the calldate column is a TIMESTAMPTZ and in
fact I'm using to do (calldate)::date in the ON clause because since the
time part of that column is always different and in the nesting I have
t
Luigi N. Puleio wrote:
If for some reason you cannot do that, please at least include the data
type of the primary key and all fields involved in the query, as well as
a list of all the indexes on both tables.
If you won't show people on the list your table definitions, or at least
the informati
>> With all that casting, is it possible that appropriate indexes aren't
>> being used because your WHERE / ON clauses aren't an exact type match
>> for the index?
>
> You mean to put an index on date with timestamptz datatype column?...
> Er ... I'm not quite sure what you mean. Do you mean an i
Luigi N. Puleio wrote:
>> With all that casting, is it possible that appropriate indexes aren't
>> being used because your WHERE / ON clauses aren't an exact type match
>> for the index?
>
> You mean to put an index on date with timestamptz datatype column?...
Er ... I'm not quite sure what you
>> SELECT
>> (a.column1)::date, MIN(b.column2) - a.column2
>> FROM
>> table a
>> inner join table b
>> on ((a.column1)::date = (b.column1)::date amd
>> b.column3 = 'b' and (b.column1)::time without time
>> zone >= (a.column1)::time without time zone)
>> WHERE
>> (a.colum
Luigi N. Puleio wrote:
> SELECT
> (a.column1)::date, MIN(b.column2) - a.column2
> FROM
> table a
> inner join table b
> on ((a.column1)::date = (b.column1)::date amd
> b.column3 = 'b' and (b.column1)::time without time
> zone >= (a.column1)::time without time zone)
> WHERE
--- Pavan Deolasee <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 9, 2008 at 3:21 PM, Luigi N. Puleio
> <[EMAIL PROTECTED]> wrote:
> > Hello everyone!!
> >
> > I have a table with 17 columns and it has almost
> > 53 records and doing just a
> >
> > SELECT * FROM table
> >
> > with the EXPLAIN AN
On Wed, 9 Apr 2008, Pavan Deolasee wrote:
I have a table with 17 columns and it has almost
53 records and doing just a
SELECT * FROM table
Well, PK won't help you here because you are selecting all rows
from the table and that seq scan is the right thing for that.
Yes. Like he said.
Pavan Deolasee wrote:
> Anyways, I don't think there is much
> tweaking you can do for such a query except making sure that
> your table is not bloated with dead tuples.
To the OP:
More explicitly: Make sure you use autovacuum or run VACUUM manually on
the table periodically.
Would I be correct
On Wed, Apr 9, 2008 at 3:21 PM, Luigi N. Puleio <[EMAIL PROTECTED]> wrote:
> Hello everyone!!
>
> I have a table with 17 columns and it has almost
> 53 records and doing just a
>
> SELECT * FROM table
>
> with the EXPLAIN ANALYZE I get:
>
> Seq Scan on table (cost=0.00...19452.95 rows=5293
Hello everyone!!
I have a table with 17 columns and it has almost
53 records and doing just a
SELECT * FROM table
with the EXPLAIN ANALYZE I get:
Seq Scan on table (cost=0.00...19452.95 rows=529395
width=170) (actual time=0.155...2194.294 rows=529395
loops=1)
total runtime=3679.039 ms
and
12 matches
Mail list logo
