From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | Alexander Stoddard <alexander(dot)stoddard(at)gmail(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Accounting for between table correlation |
Date: | 2021-01-15 21:40:08 |
Message-ID: | 13c7b2eb-2c29-9808-0b88-2d17c195921b@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 1/15/21 11:54 AM, Adrian Klaver wrote:
> On 1/15/21 10:49 AM, Alexander Stoddard wrote:
>
> Please reply to list also.
> Ccing list.
>
>>
>> So to be clear, the process imports the data, then you run a query
>> and
>> it completes in x time, you then ANALYZE the same data and it runs
>> in y
>> time. Is that correct?
>>
>> The process imports data, ANALYZE is run and then queries run in x time.
>> A subsequent ANALYZE, may or may not, change the time to y.
>> x may be greater or less than y for any given pair of runs, and the
>> difference is vast. Two very different performance domains, due to the
>> plan, I believe. If I am correctly reading the EXPLAIN plans the row
>> estimates are always way off (and low), regardless of if a high or low
>> performing plan is actually chosen.
>
> Well I'm going to say this is not going to get a useful answer without
> some concrete numbers. Too many variables involved to just start
> guessing at solutions.
Not sure if it would work for the vendor or not but:
offers an option to obfuscate EXPLAIN/ANALYZE output.
>
>>
>> Thank you,
>> Alex
>
>
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2021-01-15 21:57:39 | Re: Best tools to monitor and fine tune postgres |
Previous Message | Niels Jespersen | 2021-01-15 21:11:44 | Re: time-based range partitioning and truncate/delete different timezones |