On 11.10.2012 17:15, Korisk wrote:
> "IOS scan" ?
> Index Only Scan
>
> What's your seq_page_cost and random_page_cost?
>
> hashes=# SELECT name, setting, reset_val FROM pg_settings WHERE setting <>
> reset_val;
> name |setting | reset_val
> -
On 12.10.2012 09:10, Sergey Konoplev wrote:
> What I can not understand is why the seq scan's estimated cost is
> better the index scan's one. It depends on the number of pages in
> index/relation. May be the index is heavily bloated?
The IOS cost depends on other things too. The index can't be re
> What I can not understand is why the seq scan's estimated cost is
> better the index scan's one. It depends on the number of pages in
> index/relation. May be the index is heavily bloated?
Mm i don't know how to see bloating level. But the index was created by
create index on hashcheck using btr
On Thu, Oct 11, 2012 at 9:14 PM, Korisk wrote:
> Strange situation.
> After indexscan enabling the cost is seriously decreased.
AFAIK when the planner has to choose between index scans and seq scans
and both of this options are off it uses one of this strategies anyway
but puts 100.00 as
Hi,
On 12 October 2012 15:14, Korisk wrote:
> Strange situation.
> After indexscan enabling the cost is seriously decreased.
You can not really disable any scan method. enable_xxx = off just sets
very high cost (=100) for that operation.
--
Ondrej Ivanic
(ondrej.iva...@gmail.com)
(http
Strange situation.
After indexscan enabling the cost is seriously decreased.
hashes=# set enable_bitmapscan=on;
SET
hashes=# explain analyse verbose select name, count(name) as cnt from
hashcheck group by name order by name desc;
On Thu, Oct 11, 2012 at 8:55 PM, Korisk wrote:
> hashes=# explain analyse verbose select name, count(name) as cnt from
> hashcheck group by name order by name desc;
Now set enable_bitmapscan and enable_indexscan to on an try it again.
Then set enable_seqscan to on and run it one more time.
>
Again the same cost.
hashes=# SELECT name, setting, reset_val FROM pg_settings WHERE setting <>
reset_val;
name |setting | reset_val
-++---
archive_command | (disabled) |
enable_bitmapscan | off
On Thu, Oct 11, 2012 at 8:15 AM, Korisk wrote:
> What's your seq_page_cost and random_page_cost?
> hashes=# SELECT name, setting, reset_val FROM pg_settings WHERE setting <>
> reset_val;
> name |setting | reset_val
> -++-
"IOS scan" ?
Index Only Scan
What's your seq_page_cost and random_page_cost?
hashes=# SELECT name, setting, reset_val FROM pg_settings WHERE setting <>
reset_val;
name |setting | reset_val
-++---
archive_command
On Wed, Oct 10, 2012 at 9:13 PM, Korisk wrote:
>-> Index Only Scan Backward using hashcheck_name_idx on public.hashcheck
> (cost=100.00..1398674.92 rows=25986792 width=32)
It seems odd.
Is it possible to look at the non default configuration?
SELECT name, setting, reset_val F
On 10/11/2012 12:13 PM, Korisk wrote:
Thanx for the advice, but increment table is not acceptable because it should
be a plenty of them.
Nevertheless in the investigations was achieved some progress (7.4 sec vs 19.6
sec).
But using IOS scan
"IOS scan" ?
Do you mean some kind of I/O monitorin
Thanx for the advice, but increment table is not acceptable because it should
be a plenty of them.
Nevertheless in the investigations was achieved some progress (7.4 sec vs 19.6
sec).
But using IOS scan you can see that there is an abnormal cost calculations it
make me suspicious of little bug
On Wed, Oct 10, 2012 at 9:09 AM, Korisk wrote:
> Hello! Is it possible to speed up the plan?
> Sort (cost=573977.88..573978.38 rows=200 width=32) (actual
> time=10351.280..10351.551 rows=4000 loops=1)
>Output: name, (count(name))
>Sort Key: hashcheck.name
>Sort Method: quicksort Me
Hello! Is it possible to speed up the plan?
hashes=# \d hashcheck
Table "public.hashcheck"
Column | Type| Modifiers
+---+
id
I have table:
create table hashcheck(id serial, name varchar, value varchar);
and query:
hashaggr=# explain analyse verbose select name, count(name) as cnt from
hashcheck group by name order by name desc;
QUERY PLAN
16 matches
Mail list logo
