Received: from makus.postgresql.org ([98.129.198.125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TMAXu-00064I-P0 for pgsql-performance@postgresql.org; Thu, 11 Oct 2012 04:38:54 +0000 Received: from mail-da0-f46.google.com ([209.85.210.46]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TMAXs-00026e-Nj for pgsql-performance@postgresql.org; Thu, 11 Oct 2012 04:38:53 +0000 Received: by mail-da0-f46.google.com with SMTP id n41so542515dak.19 for ; Wed, 10 Oct 2012 21:38:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=Lu3Br+fkeuzQO/NPxR55RVGxVPhmcZYrFz8ffNqABLM=; b=MjV5RVZFWA/1q0Sv7xOarmeT+a83P1MeepGFr4jZS45dLqzwtEk4YIN27h6WtaRMU8 UKYOvUbIzTVwTTPj/mjdKtiWgPFDSJJJyZ6ltgYh3cosBBXfF/xEd6Kt8sKiBFrxLilZ Zg6RB6HWNAsgm+EwzcZsyqGx1r73wNsVVCVNnsgcqmK28gZTDkwEAjEw/t4vpJ8+JJNw 8ItFwBkZZogZndrtRrehNI7h2qL7t0im1nikUEdhRvY8FXU1XR8yo1DyeaAFfXYJ4uS0 0uZ5ldbxy0sqyj8tQBbiFBlXXDLvd5uWLhLcNzNyDGy/AgiBTYhSEZXuu3V9trpm/kGF DrZQ== Received: by 10.68.204.66 with SMTP id kw2mr80129409pbc.110.1349930330673; Wed, 10 Oct 2012 21:38:50 -0700 (PDT) Received: from ayaki.localdomain (office1.postnewspapers.com.au. [150.101.171.128]) by mx.google.com with ESMTPS id ky6sm2101574pbc.18.2012.10.10.21.38.47 (version=SSLv3 cipher=OTHER); Wed, 10 Oct 2012 21:38:49 -0700 (PDT) Message-ID: <50764D55.2060401@ringerc.id.au> Date: Thu, 11 Oct 2012 12:38:45 +0800 From: Craig Ringer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: Korisk CC: Sergey Konoplev , "pgsql-performance@postgresql.org" Subject: Re: hash aggregation References: <118871349885342@web16f.yandex.ru> <323831349928808@web5g.yandex.ru> In-Reply-To: <323831349928808@web5g.yandex.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnAhvthQLlzzvQjQDguNhcjjFJnTB06i+D1Xu22NRGjJzFyfqoyULZ/8HifKT59ZUSdaq0P X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201210/140 X-Sequence-Number: 48099 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 monitoring tool? > you can see that there is an abnormal cost calculations it make me suspicious of little bugs. Abnormal how? The cost estimates aren't times, I/Os, or anything you know, they're a purely relative figure for comparing plan costs. > hashes=# set enable_seqscan = off; > SET What's your seq_page_cost and random_page_cost? > hashes=# explain analyse verbose select name, count(name) as cnt from hashcheck group by name order by name desc; > QUERY PLAN > ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > GroupAggregate (cost=10000000000.00..10000528610.88 rows=200 width=32) (actual time=0.116..7452.005 rows=4001 loops=1) > Output: name, count(name) > -> Index Only Scan Backward using hashcheck_name_idx on public.hashcheck ^^^^^^^^^^^^^^^^^^^^^^^^ If you don't mind the increased cost of insert/update/delete try: CREATE INDEX hashcheck_name_rev_idx ON public.hashcheck (name DESC); ie create the index in descending order. -- Craig Ringer