Андрей Мохов

очевидно же - вирусня

как-то так:

WITH item_codes_ordered as (
        SELECT ic.*,
            COUNT(*) OVER (PARTITION BY EXTRACT(YEAR FROM ic.t) ORDER BY ic.id ASC) as a,
            COUNT(*) OVER (PARTITION BY EXTRACT(YEAR FROM ic.t) ORDER BY ic.id DESC) as d
        FROM item_codes ic
    )
SELECT ic_a.t as t_asc,
    ic_a.item_code as item_code_asc,
    ic_d.t as t_desc,
    ic_d.item_code as item_code_desc
FROM item_codes_ordered ic_a
INNER JOIN item_codes_ordered ic_d ON ic_d.d = 1 AND EXTRACT(YEAR FROM ic_d.t) = EXTRACT(YEAR FROM ic_a.t)
WHERE ic_a.a = 1

как-то так

SELECT str_to_date(t.`date`, '%d-%m-%Y') - interval mod(dayofweek(str_to_date(t.`date`, '%d-%m-%Y'))+5, 7) day as week_start, count(*) as cnt
FROM yourtable t
WHERE t.status=1
GROUP BY week_start

$users[0] содержит следующую строку: "Vlad\n", смотрите функцию file, дословно из документации:

Возвращает файл в виде массива. Каждый элемент массива соответствует строке файла, с символами новой строки включительно.

поэтому при сравнении вы имеете результат отличный от 0

если вы реализовываете интерфейс, то вы должны реализовать все методы, объявленные в нем

SELECT *
FROM users
WHERE date_format(now(), '%m-%d') = date_format(birthday, '%m-%d')

эмн... а в чем проблема?

INSERT INTO normalized.table1
SELECT * FROM public.table1

может одноименная вьюха есть?

можно выполнить запрос и по его результатам узнать есть ли таблица:

SELECT *
FROM pg_tables
WHERE tablename = 'search_table_name'

preg_match_all('/:(\d+)/', ':475440 :472710 :2730', $matches);
print_r($matches[1]);

имя базы данных пишется без апострофов, в крайнем случае в обратных апострофах `dbname`.*

две буквы: слэш и маленькая латинская эн по вашему специсимволы? браво!

tinyint + триггеры на вставку/обновление для проверки допустимого диапазона значений

в google забанили чтоль?

для начала преобразуйте в InnoDB, всегда нужно смотреть вследствие чего возникает нагрузка и действовать в соответствии с обстоятельствами, есть ли запросы, которые изменяют таблицу...
также хорошей оптимизацией будет рост в ширину, т.е. настройка репликации для снижения нагрузки на одну СУБД

могу предположить следующее: таблица post очень большая (много записей), в этом случае индекс по первичному ключу может не уместиться в буфере (см. настройки), следовательно СУБД будет читать все значения таблицы, сортировать их и выдавать результат