Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e6xZq-0000Sv-NS for pgsql-performance@arkaria.postgresql.org; Tue, 24 Oct 2017 11:40:58 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1e6xZp-0003yB-6W for pgsql-performance@arkaria.postgresql.org; Tue, 24 Oct 2017 11:40:57 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1e6xY2-0000oB-PC for pgsql-performance@postgresql.org; Tue, 24 Oct 2017 11:39:06 +0000 Received: from mail-wm0-x22c.google.com ([2a00:1450:400c:c09::22c]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1e6xXz-00009H-1s for pgsql-performance@postgresql.org; Tue, 24 Oct 2017 11:39:06 +0000 Received: by mail-wm0-x22c.google.com with SMTP id u138so15092228wmu.5 for ; Tue, 24 Oct 2017 04:39:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VyH9s5BDnFBbfiDa57J4UImnkPAXXqOYHwfDABgxnJs=; b=nJ38SZs5tIWA/474TyGqFcLgL9Qv8pNj8oUjUGsIKNrdDaLb0bcRyR0T6LEI5EV5QL CXd0Mhvt5XloSn+szyGb0JpOpXzTKGs+tRZAHdstmAj8+W/d0AyAk5TK52E9sF6gXjtr vyIwDOgTUPzQz6Sek1bmWWlMR6Qgx46Ros9aWoz3n/g59EWhC0mfjwpu7H4Ejp1uRBq0 IYuiU48ZeUt+QfZqVHaoCFSInWHJ6+x0zM+kpHUlfv8D1GLwIt2uIpj9t2AsgtLUnX+9 zd7/nl78EnjDglbg+3p5ZCM+THADTHJOaTCgBpj9HJKF5iULUzvF77IhpSZQQwRMVt1E hSyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VyH9s5BDnFBbfiDa57J4UImnkPAXXqOYHwfDABgxnJs=; b=Z8nmdzm5pjVMh0OesqLsW53FfvEBBETNbptkSR5ks8W39iPuoriVJUbVEBezGD8I5C VoGfFUysCAneeVB78Zetyn2YlgvKxjWsIsjacdEsVlQYW9uDVu27CaB0BC56nLA+do6d t12VfZw1AyyTpo3/U7Gef7NeV4PZXRvWKr7haFA1HMAV77a8JJqb8PArYN3zGdMyhheI rUcfP+rv54wl/kLvX7rm/YCwnZHxcKOe4/6uRa+qn/K1uiLLaukm3G6IFbj9gsywJUx/ nSBaMbSBZZ6TY7wCudGBdEZmtvazxJ1hIjRXv/5Z8eXOo/1RiyRUuF+Jddx5Ohjz/0LL JKDg== X-Gm-Message-State: AMCzsaVGDt3IA8ZLzMmDKUHWovEGJWZkpDpRMcsU6m9fvoP2gqYI/xOs Ua/C/MsFzD/irYKdE5ARKiVQfAoL0VT3LvhB+GZMKNlx X-Google-Smtp-Source: ABhQp+SlciJvUxKHM/hy5gdyBPJab5IWc9N4NUxnUBOvPVNlkuIU+XXKuUt1BpRiZiVcvyBweN86haXtXl25mT7wGUg= X-Received: by 10.28.209.200 with SMTP id i191mr7425940wmg.156.1508845141861; Tue, 24 Oct 2017 04:39:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.197.78 with HTTP; Tue, 24 Oct 2017 04:39:01 -0700 (PDT) In-Reply-To: <1508790557217-0.post@n3.nabble.com> References: <1508790557217-0.post@n3.nabble.com> From: Purav Chovatia Date: Tue, 24 Oct 2017 17:09:01 +0530 Message-ID: Subject: Re: postgresql tuning with perf To: legrand legrand Cc: pgsql-performance@postgresql.org Content-Type: multipart/alternative; boundary="94eb2c13130eb3b17e055c496273" List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org --94eb2c13130eb3b17e055c496273 Content-Type: text/plain; charset="UTF-8" Hi Pascal, Do you mean the sample program that acts as the application, do you want me to share that? I can do that, but I guess my post will get blocked. Yes, c1 is the PK. Pls see below: bmdb=# desc dept_new Table "public.dept_new" Column | Type | Modifiers --------+---------------+----------- c1 | numeric(10,0) | not null c2 | numeric(10,0) | . . . . . c205 | numeric(10,0) | Indexes: "dept_new_pkey" PRIMARY KEY, btree (c1) bmdb=# We dont analyze after loading the table. But I guess thats required only if the query plan is in doubt, lets say its doing a full table scan or alike, isnt it? That is not the case. The query is using PK index but it just seems to be slow. Thanks On 24 October 2017 at 01:59, legrand legrand wrote: > Hi, > could you providence the code used with PG ? > Has table dept_new an index/pk on c1 ? > Do you analyze this table after loading it ? > > Regards > PAscal > > > > -- > Sent from: http://www.postgresql-archive.org/PostgreSQL-performance- > f2050081.html > > > -- > Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance > --94eb2c13130eb3b17e055c496273 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Pascal,

Do you mean the sample progr= am that acts as the application, do you want me to share that? I can do tha= t, but I guess my post will get blocked.

Yes, c1 i= s the PK. Pls see below:
bmdb=3D#= desc dept_new
=C2=A0 =C2=A0 =C2=A0 Ta= ble "public.dept_new"
=C2=A0= Column |=C2=A0 =C2=A0 =C2=A0Type=C2=A0 =C2=A0 =C2=A0 | Modifiers
--------+---------------+-----------
<= div style=3D"font-size:12.8px">=C2=A0c1=C2=A0 =C2=A0 =C2=A0| numeric(10,0) = | not null
=C2=A0c2=C2=A0 =C2=A0 =C2= =A0| numeric(10,0) |
.
.
.
.
.
=C2=A0c205=C2=A0 =C2=A0| numeric(10,0) |
<= div style=3D"font-size:12.8px">Indexes:
=C2=A0 =C2=A0 "dept_new_pkey" PRIMARY KEY, btree (c1)

bmdb= =3D#

We dont analyze after loading the table= . But I guess thats required only if the query plan is in doubt, lets say i= ts doing a full table scan or alike, isnt it? That is not the case. The que= ry is using PK index but it just seems to be slow.

Thanks

On 24 October 2017 at 01:59, legrand legrand <legrand_legrand@= hotmail.com> wrote:
Hi,
could you providence the code used with PG ?
Has table dept_new an index/pk on c1 ?
Do you analyze this table after loading it ?

Regards
PAscal



--
Sent from: http://www.postgres= ql-archive.org/PostgreSQL-performance-f2050081.html


--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-pe= rformance

--94eb2c13130eb3b17e055c496273--