Am 05/23/2017 um 06:59 PM schrieb Jeff Janes:
> On Tue, May 23, 2017 at 4:03 AM, Gunnar "Nick" Bluth
> mailto:gunnar.bluth.ext...@elster.de>>
> wrote:
8>< -
>
> Unfortunately that always uses the index scan, even at a high cutoff
> where aggregation
; 0.1 0.9
view1: 348 1022
view2: 844 6484
view3: 842 5976
With
LATERAL ( SELECT string_agg(thing_alias.md5, ','::text) AS md5
FROM thing_alias
WHERE thing_alias.thing_id = thing.id
GROUP BY thing_alias.thing_id) foo
(which seems to make more sense ;-)
I yield 483 (0.1) and 3410 (0.9) ms (and return md5-Aggregates).
Cheers,
--
Gunnar "Nick" Bluth
DBA ELSTER
Tel: +49 911/991-4665
Mobil: +49 172/8853339
smime.p7s
Description: S/MIME Cryptographic Signature
e advantages of having things like monitoring, backup,
HDD replacements etc. done for you. Which is essentially what you pay for.
In essence, there's obviously no silver bullet ;-)
Best regards,
--
Gunnar "Nick" Bluth
DBA ELSTER
Tel: +49 911/991-4665
Mobil: +49 172/8853339
Am 15.12.2015 um 10:49 schrieb Andreas Kretschmer:
> Gunnar Nick Bluth wrote:
>
>> Am 15.12.2015 um 09:05 schrieb Mathieu VINCENT:
>>> Hello,
>>>
>>> No one to help me to understand this bad estimation rows ?
>>
>> Well,
>>
>>
ins for ultimate join. Can
> you help me to improve this row estimation ?
>
> Thank you for answering
>
> Best Regards,
> <http://www.psih.fr/> PSIH Décisionnel en santé
> Mathieu VINCENT
> Data Analyst
> PMSIpil
Am 06.11.2012 21:24, schrieb Petr Praus:
On 6 November 2012 14:17, Gunnar "Nick" Bluth
mailto:gunnar.bl...@pro-open.de>> wrote:
Am 06.11.2012 21:08, schrieb Petr Praus:
2MB: http://explain.depesz.com/s/ul1
4MB: http://explain.depesz.com/s/IlVu
down quite a bit.
Though I wonder why this didn't show in the original plans...
--
Gunnar "Nick" Bluth
RHCE/SCLA
Mobil +49 172 8853339
Email: gunnar.bl...@pro-open.de
__
In 1984 mainstream users were choosin
mns.
I wonder why noone actually understanding the implementation chipped in
yet... Andres, Greg, Tom, whoever actually understands what's happening
here, anyone reading this? ;-)
Cheers,
--
Gunnar "Nick" Bluth
RHCE/SCLA
Mobil +49 172 8853339
Email: gunnar.bl...@pro-open.de
Greg Smith mentions an optimization wrt. Hash Joins that can become a
pitfall. His advise is to increase the statistic targets on the hashed
outer relation. Might be worth a try.
--
Gunnar "Nick" Bluth
RHCE/SCLA
Mobil +49 172 8853
Am 03.11.2012 18:19, schrieb Petr Praus:
On 3 November 2012 12:09, Gunnar "Nick" Bluth
mailto:gunnar.bl...@pro-open.de>> wrote:
Am 03.11.2012 16:20, schrieb Petr Praus:
Your CPUs are indeed pretty oldschool. FSB based, IIRC, not
NUMA. A process migrati
query runs fast, with 96MB
it runs slow (same times as before). It really seems that the
culprit is work_mem.
Well, I'm pretty sure that having more work_mem is a good thing (tm)
normally ;-)
--
Gunnar "Nick" Bluth
RHCE/SCLA
Mobil +49 172 8853339
Email:
SHM, or in the private memory of the
backend? I can't tell, tbth), the sort takes longer than when it's using
a temp file.
What if you reduce the shared_buffers to your original value and only
increase/decrease the session's work_mem? Same behaviour?
Cheers,
--
Gunnar &quo
ork_mem in the session you're testing in (so you have
large SHM, but small work mem)
Cheers,
--
Gunnar "Nick" Bluth
RHCE/SCLA
Mobil +49 172 8853339
Email: gunnar.bl...@pro-open.de
__
In 1984 mainstream us
13 matches
Mail list logo
