Melkij

Есть View. Планировщику придёт что-то похожее на изначальный запрос и дальше он будет переписывать запрос. Т.е. что-то подобное пункту 1.

Есть Materialized Views. Это пункт 2. www.postgresql.org/docs/9.4/static/rules-materiali...

По порядку:

Повторно запрос выполняется много быстрее.

Значит, вы с головой упёрлись в диск.
Вариант есть только один - ставить быстрый диск.
Вариант похуже, т.к. диск всё равно у вас останется медленный и если не на чтении, то на старте и на записи вы туда упрётесь очень хорошо - использовать больше памяти. Чтобы как можно данных было в памяти. Но при работе эти данные всё равно надо поднимать с медленных дисков, потому базу сначала придётся разогревать. Есть даже штатная утилитка pg_prewarm

В конфиге postgresql менял настройки только авторизации.

По дефолту там что-то несмешное вместо shared_buffers. 32 что ли мегабайта? И это на ключевую характеристику базы.
Увеличивать хотя бы до 20% от общего объёма памяти на машине.

В третьих, актуальный Postgresql довольно плохо умеет развесистый IN. И тому есть не совсем очевидное решение - переписать в join:

select count(*) from test JOIN (VALUES (1),...,(10000)) AS v(val) USING (val);

Такой вот hash join работает быстрее IN. На 10000 элементах получали 10мс против 380мс у IN.

Например,

CREATE OR REPLACE FUNCTION process_data(
    s_input text
)
RETURNS void
AS $function$
DECLARE
    a_data text[];
BEGIN

    a_data := regexp_matches(s_input, '^Login: ([^;]+); IP ([\d\.]+); Time: ([\d\:\.\s]+)$');

    raise notice 'Login %', a_data[1];
    raise notice 'IP %', a_data[2];
    raise notice 'Time %', to_timestamp(a_data[3], 'DD.MM.YYYY HH24:MI:SS');

END;
$function$
LANGUAGE plpgsql STABLE SECURITY DEFINER;

Туннель, может лучше будет сделать?
Поверх SSH или какой-нибудь VPN.

Как ни странно, но, может быть, таких строк действительно нет?

Что по этому поводу думает мануал:
www.postgresql.org/docs/current/static/continuous-...

Some file system backup tools emit warnings or errors if the files they are trying to copy change while the copy proceeds. When taking a base backup of an active database, this situation is normal and not an error. However, you need to ensure that you can distinguish complaints of this sort from real errors. For example, some versions of rsync return a separate exit code for «vanished source files», and you can write a driver script to accept this exit code as a non-error case. Also, some versions of GNU tar return an error code indistinguishable from a fatal error if a file was truncated while tar was copying it. Fortunately, GNU tar versions 1.16 and later exit with 1 if a file was changed during the backup, and 2 for other errors. With GNU tar version 1.23 and later, you can use the warning options --warning=no-file-changed --warning=no-file-removed to hide the related warning messages.

Т.е. wal-логи нужны, но на их изменения в процессе работы бекапа внимания можно не обращать. Почитайте в мане rsync'а, может ли он игнорировать модификацию файлов.

Update:
За прошедшие года с момента этого ответа я успешно переквалифицировался в postgresql DBA. И могу сказать, что корректен ответ vyegorov. Используйте штатный pg_basebackup с указанием --xlog (для 9.1 + внимание на предупреждение в мануале) или --xlog-method=stream для более новых.

А вот что-либо "чинить" через pg_resetxlog настоятельно не рекомендую. В итоге вы получите непонятно что вместо согласованного состояния базы. Так как именно по xlog база приходит в согласованное транзакциионное состояние при старте.