nchronous_commit=off is very ok and provides a
lot of performance gain.
--
Guillaume Cottenceau
,11290332,11290333,11290431',',')::int[];
count
---
4
(1 row)
Time: 52.335 ms
db=> select count(*) from table where array[uid] <@
string_to_array('11290331,11290332,11290333,11290431',',')::int[];
count
---
4
(1 row)
Time: 44.176 ms
--
Guillaume Cottenceau
are running postgresql 11.5, with 2GB
shared_buffers. Differences I can think of: production is using
ext4 on drbd on SATA and linux 3.2, dev is using ext4 (no drbd)
on SSD and linux 4.15. I can't believe SSD would explain the
difference alone? If positive, then I know what we should do on
production..
Thanks for any hints/help!
--
Guillaume Cottenceau
Justin Pryzby writes:
> On Wed, Feb 26, 2020 at 05:17:21PM +0100, Guillaume Cottenceau wrote:
>> On production:
>>
>> # EXPLAIN ANALYZE SELECT transaction_uid, (SELECT COUNT(*) FROM tickets
>> WHERE multicard_uid = mult
UPDATE multicards
SET defacements = count
FROM ( SELECT multicard_uid, COUNT(*) AS count FROM tickets GROUP BY
multicard_uid ) AS sub
WHERE uid = multicard_uid;
Any hinted solution to do that in one pass? I could do a first
pass setting defacements = 0, but that would produce more garbage :/
Thanks!
--
Guillaume Cottenceau
ure of performance of course.
This looked great but as it seems you suspected, it's very slow :/
I interrupted it after 5 minutes run on my dev computer.
--
Guillaume Cottenceau
Jeff Janes writes:
> On Wed, Feb 26, 2020 at 1:02 PM Guillaume Cottenceau wrote:
>
> It is actually consistent with using a restored backup on the dev
> computer, as my understanding is this comes out without any
> garbage and like a perfectly vacuumed database.
>
&g
