do you need all of verbose information??
VACUUM FULL ANALYZE VERBOSE give me a lot of infomation,
so i just cut zipcode parts.
==start===
INFO:Â vacuuming "public.zipcode"
INFO:Â "zipcode": found 0 removable, 47705 non
Hyun-Sang,
> before test, I already executed VACUUM FULL.
> this result show up after vacuum full.
Really? Your results really look like a bloated table. Can you run VACUUM
FULL ANALYZE VERBOSE on the table and post the output?
> When I using index scan, the result was almost same, that mea
before test, I already executed VACUUM FULL.
this result show up after vacuum full.
Tom Lane ì ê:
=?UTF-8?B?7J6l7ZiE7ISx?= <[EMAIL PROTECTED]> writes:
but, sequence scan, as you see above result, there is big time
difference between using LIMIT and without using it.
Y
=?UTF-8?B?7J6l7ZiE7ISx?= <[EMAIL PROTECTED]> writes:
> but, sequence scan, as you see above result, there is big time
> difference between using LIMIT and without using it.
You've got a table full of dead rows. Try VACUUM FULL ...
regards, tom lane
-
Sorry, i can't check this easily as I don't have any date fields in my data
(they all held has character strings - do as i say, not as i do) but maybe
you should cast or convert the string representation of the date to a date
in the where clause. Postgres might be doing some implicit conversion
hello~
i'm curious about this situation.
here is my test.
my zipcode table has 47705 rows,
and schema looks like this.
pgsql=# \d zipcode
Table "public.zipcode" Column | Type | Modifiers
-+---+--- zipcode | character(7) |
not null sido | character varying(4) |
Hi. Thanks for your reply. The date column data type is date already. :D
-Original Message-
From: Iain [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 01, 2004 12:00 PM
To: BBI Edwin Punzalan; 'gnari'; [EMAIL PROTECTED]
Subject: Re: [PERFORM] FW: Index usage
If it's any help, i ju
If it's any help, i just ran this test on 7.4.6, my table has about 700
rows and the index is an integer.
The item id ranges from 1 to 2.
As you can see from the following plans, the optimizer changed it's plan
depending on the value of the item id condition, and will use an index when
Thanks but whatever it does, it didn't work. :D
Do you think upgrading will fix this problem?
=
db=# alter table chatlogs alter column date set statistics 300;
ALTER
db=# analyze chatlogs;
ANALYZE
db=# explain analyze select * from chatlogs where date >= '12/1/04';
NOTICE
From: "BBI Edwin Punzalan" <[EMAIL PROTECTED]>
>
> Hi, what do you mean by increasing the statistics on the date column?
alter table chatlogs alter column date set statistics 300;
analyze chatlogs;
> > > Our version is 7.2.1
> >
> > upgrade time ?
>
> We never had any upgrade on it.
7.2 is
Hi, what do you mean by increasing the statistics on the date column?
We never had any upgrade on it.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of gnari
Sent: Thursday, November 25, 2004 3:13 AM
To: BBI Edwin Punzalan; [EMAIL PROTECTED]
Subject: Re: [
Bo,
> 2 - 2.4 Ghz Xeon processors
> 4GB ram
> 4 36gb 1rpm scsi drives configured for raid 10
Hopefully you've turned OFF hyperthreading?
> gains can I expect on average from swapping from 4 disk raid 10 to 14 disk
> raid 10? Could I expect to see 40 - 50% better throughput.
This is so depe
Did you test with ILIKE instead of lower LIKE lower ?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of sdfasdfas
sdfasdfs
Sent: mercredi 24 novembre 2004 18:37
To: [EMAIL PROTECTED]
Subject: [PERFORM] "Group By " index usage
I have a table with this in
On 30 Nov 2004 14:30:37 +0100, Dmitry Karasik <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> On v7.4.5 I noticed downgrade in the planner, namely favoring
> sequential scan over index scan. The proof:
>
>create table a ( a integer);
>create index aidx on a(a);
>explain analyze select * f
On 11/30/2004 7:30 AM Dmitry Karasik said::
Hi all,
On v7.4.5 I noticed downgrade in the planner, namely favoring
sequential scan over index scan. The proof:
create table a ( a integer);
create index aidx on a(a);
explain analyze select * from a where a = 0;
-- Index Scan using aidx on a (
Hi all,
On v7.4.5 I noticed downgrade in the planner, namely favoring
sequential scan over index scan. The proof:
create table a ( a integer);
create index aidx on a(a);
explain analyze select * from a where a = 0;
-- Index Scan using aidx on a (cost=0.00..17.07 rows=5 width=4) (act
16 matches
Mail list logo
