#!/bin/bash
cd /path/to/repository
mysql -u ПОЛЬЗОВАТЕЛЬ -pПАРОЛЬ -D БАЗА_ДАННЫХ -N -B > table_employees.json <<EOF
SELECT JSON_PRETTY(JSON_ARRAYAGG(
JSON_OBJECT("id", id, "name", name, "age", age)
)) json
FROM employees;
EOF
git add table_employees.json
git commit -F table_employees.json -m 'table_employees.json `date +"%Y-%m-%d %H:%M:%S"`'
git push
в минуту добавляються по 5000
решили поменять немного архитектуру чтобы запрос был более лёгкий
А как правильнее через переменную реализовать?
var isValidEmail = !/@(gmail|yahoo)\.[a-z]+$/.test(input.value.trim().toLowerCase());
/@(gmail|yahoo)\.[a-z]+$/.test(input.value.trim().toLowerCase())
!/@(gmail|yahoo)\.[a-z]+$/.test(input.value.trim().toLowerCase())
- work_mem. Под каждый запрос можно выделить личный ограниченный объём памяти для работы. Этот объём может использоваться для сортировки, объединения и других подобных операций. При превышении этого объёма сервер начинает использовать временные файлы на диске, что может существенно замедлить скорость обработки запросов. Предел для work_mem можно вычислить, разделив объём доступной памяти (физическая память минус объём занятый под другие программы и под совместно используемые страницы shared_buffers) на максимальное число одновременно используемых активных соединений. При необходимости, например, выполнения очень объёмных операций, допустимый лимит можно изменять прямо во время выполнения запроса. Поэтому нет нужды изначально задавать теоретический предел.
- effective_cache_size Этот параметр сообщает PostgreSQL примерный объём файлового кэша операционной системы, оптимизатор использует эту оценку для построения плана каждого запроса. Объём задаётся параметром effective_cache_size в postgresql.conf. Единица измерения – блоки величиной 8 кБ. Например, пусть в вашем компьютере 1,5 ГБ памяти, параметр shared_buffers установлен в 32 МБ, а параметр effective_cache_size в 800 МБ. Если запросу нужно 700 МБ данных, то PostgreSQL оценит, что все нужные данные уже есть в памяти и выберет более агрессивный план с использованием индексов и merge joins. Но если effective_cache_size будет всего 200 МБ, то оптимизатор вполне может выбрать более эффективный для дисковой системы план, включающий полный просмотр таблицы. В качестве начального значения можете использовать 25-50% доступной памяти (т.е. не занятой операционной системой и приложениями). Этот параметр в ОС можно посмотреть в настройках: Для Windows: в Диспетчере задач, Закладка Быстродействие, Физическая память-Системный кэш. Для Linux: наберите команду free, необходимое значение в столбце cached (в kB) Данное значение необходимо разделить на количество конкурентных запросов в один момент времени (среднее количество подключений к базе + запас).
- maintenance_work_mem. Эта память используется для выполнения операций по сбору статистики (ANALYZE), сборке мусора (VACUUM), создания индексов (CREATE INDEX) и для добавления внешних ключей (FOREGIN KEY). Размер выделяемой под эти операции памяти должен быть сравним с физическим размером самого большого индекса на диске. Как и в случае work_mem эта переменная может быть установлена прямо во время выполнения запроса.
- max_prepared_transactions. Определяет максимальное число подготовленных транзакций (команда PREPARE TRANSACTION). Подготовленные транзакции выполняются, но результат их не будет доступен пока их не подтвердят (COMMIT). Так же можно такие транзакции и отклонить (ROLLBACK). Если эта сущность нигде не используется, то переменную можно занулить.
shared_buffers = 5GB # ~ 1/8 RAM
work_mem = 2GB # ~ 1/20 RAM
maintenance_work_mem = 10GB # ~ 1/4 RAM
effective_cache_size = 23GB # ~ 2/3 RAM
work_mem. Под каждый запрос можно выделить личный ограниченный объём памяти для работы. Этот объём может использоваться для сортировки, объединения и других подобных операций. При превышении этого объёма сервер начинает использовать временные файлы на диске, что может существенно замедлить скорость обработки запросов. Предел для work_mem можно вычислить, разделив объём доступной памяти (физическая память минус объём занятый под другие программы и под совместно используемые страницы shared_buffers) на максимальное число одновременно используемых активных соединений. При необходимости, например, выполнения очень объёмных операций, допустимый лимит можно изменять прямо во время выполнения запроса. Поэтому нет нужды изначально задавать теоретический предел.
SET work_mem = '2GB'; -- например
SELECT q.id
FROM questions.question q
LEFT JOIN questions.question_translate_it qt ON q.id = qt.question_id
LEFT JOIN questions.translate_questions tq ON q.id = tq.question_id AND tq.language_id = 8
WHERE qt.question_id IS NULL
AND tq.question_id IS NULL
LIMIT 1
;
не понимаете, зачем нужна функция move_uploaded_file
загружает файл его нужно переместить
move_uploaded_file — Перемещает загруженный файл в новое место<?php $uploads_dir = '/uploads'; foreach ($_FILES["pictures"]["error"] as $key => $error) { if ($error == UPLOAD_ERR_OK) { $tmp_name = $_FILES["pictures"]["tmp_name"][$key]; // basename() может предотвратить атаку на файловую систему; // может быть целесообразным дополнительно проверить имя файла $name = basename($_FILES["pictures"]["name"][$key]); move_uploaded_file($tmp_name, "$uploads_dir/$name"); } } ?>
SELECT q.id
FROM questions.question q
LEFT JOIN questions.question_translate_it qt ON q.id = qt.question_id
LEFT JOIN (SELECT question_id FROM questions.translate_questions WHERE language_id = 8) tq ON q.id = tq.question_id
WHERE qt.question_id IS NULL
AND tq.question_id IS NULL
LIMIT 1
;
PS: то что там по дефолту выставляется на сервер, имхо полная шляпа, они там и пишут AS IS и никакой ответственности.