Hi Andrew -
On Mon, Jan 7, 2019 at 12:00 AM Andrew Gierth
wrote:
> > "Alexander" == Alexander Farber writes:
> Alexander> With the further help of the IRC folks the query has been
> Alexander> optimized (7-10 seconds -> 0.3 second)
>
> 0.3 MILLIseconds, actually.
>
> (You chanced not to c
> "Alexander" == Alexander Farber writes:
Alexander> Good evening, thank you for the useful hints!
Alexander> With the further help of the IRC folks the query has been
Alexander> optimized (7-10 seconds -> 0.3 second)
0.3 MILLIseconds, actually.
(You chanced not to catch me around on IR
Alexander Farber wrote
> Good evening, thank you for the useful hints!
>
> With the further help of the IRC folks the query has been optimized (7-10
> seconds -> 0.3 second) by adding the following indices:
>
> CREATE INDEX ON words_games (player1, COALESCE(finished, 'INFINITY'));
> CREATE INDEX
Good evening, thank you for the useful hints!
With the further help of the IRC folks the query has been optimized (7-10
seconds -> 0.3 second) by adding the following indices:
CREATE INDEX ON words_games (player1, COALESCE(finished, 'INFINITY'));
CREATE INDEX ON words_games (player2, COALESCE(fin
Oh ok, so it is not as simple as eliminating all "Seq Scan" occurrences...
Thank you for replying Andrew -
On Sat, Jan 5, 2019 at 9:18 PM Andrew Gierth
wrote:
That seems slow in itself, even before adding the extra join - the
> explain suggests that you're both short on indexes and you're getti
> "AF" == Alexander Farber writes:
AF> Here are the only modified settings in postgresql.conf:
AF> max_connections = 120 # (change requires restart)
AF> work_mem = 8MB # min 64kB
AF> maintenance_work_mem = 128MB # min 1MB
AF> 90% of the backend source code are JSON-emitting
