o all,
Daniel
-Original Message-
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Francisco Olarte
Sent: June-11-15 10:05
To: Daniel Begin
Cc: Bill Moran; pgsql-general@postgresql.org; Tomas Vondra; Melvin Davidson
Subject: Re: [GENERAL] Pl
Hi Daniel:
On Thu, Jun 11, 2015 at 2:38 PM, Daniel Begin wrote:
.
> The remaining problem seems related to the statistics of some large tables.
> On one hand, I might increase the statistic target for these tables to 500,
> or even to 1000 and look at the results (but I have doubts it will he
#x27;Melvin Davidson'
Subject: Re: [GENERAL] Planner cost adjustments
On Wed, 10 Jun 2015 17:20:00 -0400
Daniel Begin wrote:
> Here is a follow-up on adjusting the planner costs calculation
>
> -Statistics target of problematic columns were increased from 100 to 200.
> -An
hould I increase the statistic target to 500, or even
> to 1000?
> Is there something else I can trigger to get the appropriate plan?
>
> Comments/explanations would be appreciated
> Daniel
>
>
> -Original Message-
> From: pgsql-general-ow...@postgresql.org
> [m
-03-15 06:32
To: 'Bill Moran'
Cc: pgsql-general@postgresql.org; 'Tomas Vondra'; 'Melvin Davidson'
Subject: Re: [GENERAL] Planner cost adjustments
Thank Bill,
About disks performance, all drives are identical and connected using USB3
connections and yes, I can tweak val
Daniel Begin wrote:
> I can tweak values and restart Postgres without any hardship!
Many of the important performance-related settings (especially cost
factors) can be adjusted with the SET command to affect just the
one connection. This can make experimenting a lot easier.
> About seq_page_co
@postgresql.org; 'Tomas Vondra'; 'Melvin Davidson'
Subject: Re: [GENERAL] Planner cost adjustments
On Tue, 2 Jun 2015 14:01:35 -0400
Daniel Begin wrote:
> Here is a follow-up on the step-by-step procedure proposed by PT
>
> #1 - setup postgresql planner's cost
On Tue, 2 Jun 2015 14:01:35 -0400
Daniel Begin wrote:
> Here is a follow-up on the step-by-step procedure proposed by PT
>
> #1 - setup postgresql planner's cost estimate settings for my hardware.
>
> --
> Curr
Here is a follow-up on the step-by-step procedure proposed by PT
#1 - setup postgresql planner's cost estimate settings for my hardware.
--
Current parameters values described in section 18.7.2 haven't been chang
ral@postgresql.org; 'Melvin Davidson'
Subject: Re: [GENERAL] Planner cost adjustments
Hi,
On 05/29/15 22:56, Daniel Begin wrote:
> Omg! I was not expecting such a step-by-step procedure, thanks!
> I'll follow the guide :-)
>
> Since I was about to provide a bit of con
Hi,
On 05/29/15 22:56, Daniel Begin wrote:
Omg! I was not expecting such a step-by-step procedure, thanks!
I'll follow the guide :-)
Since I was about to provide a bit of context as asked by Tomas, here it is
for those who are interested...
Best regards,
Daniel
A bit of the required context...
age = 5000
vacuum_freeze_table_age = 15000
vacuum_multixact_freeze_min_age = 500
vacuum_multixact_freeze_table_age= 15000
-Original Message-
From: PT [mailto:wmo...@potentialtech.com]
Sent: May-29-15 16:35
To: Daniel Begin
Cc: pgsql-general@postgresql.org
Subject: Re
On Fri, 29 May 2015 09:39:00 -0400
Daniel Begin wrote:
> Hi all,
>
> Running some queries, I found that the planner often selects sequential scan
> instead of an index scan, even if the latter is way faster (one order of
> magnitude faster if I consider some tests I made by setting enable_seqsca
Hi,
On 05/29/15 17:22, Melvin Davidson wrote:
I have found that setting
enable_seqscan = off
will remedy that situation. Basically, it forces the planner to
choose the index. However, if no correct index is available, it will
use sequential scan anyway. The only time it will have a negative
ef
I have found that setting
enable_seqscan = off
will remedy that situation. Basically, it forces the planner to choose the
index. However, if no correct index is available, it will use sequential
scan anyway. The only time it will have a negative effect is if the seqscan
is actually faster, which
Hi all,
Running some queries, I found that the planner often selects sequential scan
instead of an index scan, even if the latter is way faster (one order of
magnitude faster if I consider some tests I made by setting enable_seqscan =
ON/OFF). How can I figure out what parameter I should adjust to
16 matches
Mail list logo
