thefish
PostgreSQL костыли 2ndquadrant.com

Here is a recipe for dealing with the problem. It won’t necessarily work for every situation, particularly tables with very heavy write loads, but it could work for many.

First let’s set up our sample table and populate it with some data, 10 million rows in this case:
```
create table orig_table
( id serial not null,
data float default random()
);

create index orig_data_index on orig_table(data);
create index orig_id_index on orig_table(id);

insert into orig_table (id)
select nextval('orig_table_id_seq')
from generate_series(1,100000);
```
Now we’re going to set up the partitioning structure. In this case we’re going to use four ranges on the data field:
```
create table part_table
(like orig_table including defaults including indexes including constraints)
partition by range(data);

create table part_table_p1
partition of part_table
for values from (minvalue) to (0.25);

create table part_table_p2
partition of part_table
for values from (0.25) to (0.5);

create table part_table_p3
partition of part_table
for values from (0.5) to (0.75);

create table part_table_p4
partition of part_table
for values from (0.75) to (maxvalue);
```
we’ll need a trigger function to handle all the insert, update and delete operations for the view.
```
create or replace function part_v_trigger()
returns trigger
language plpgsql
as
$TRIG$

begin
IF TG_OP = 'INSERT'
THEN
INSERT INTO part_table VALUES(NEW.id, NEW.data);
RETURN NEW;
ELSIF TG_OP = 'DELETE'
THEN
DELETE FROM part_table WHERE id = OLD.id;
DELETE FROM old_orig_table WHERE id = OLD.id;
RETURN OLD;
ELSE — UPDATE
DELETE FROM old_orig_table WHERE id = OLD.id;
IF FOUND
THEN
INSERT INTO part_table VALUES(NEW.id, NEW.data);
ELSE
UPDATE part_table SET id = NEW.id, data = NEW.data
WHERE id = OLD.id;
END IF;
RETURN NEW;
END IF;
end

$TRIG$;
```
Then we can move to the transitional setup in one quick transaction, we disable autovacuum on it.
```
BEGIN;

ALTER TABLE orig_table RENAME TO old_orig_table;

ALTER TABLE old_orig_table SET(
autovacuum_enabled = false, toast.autovacuum_enabled = false
);

CREATE VIEW orig_table AS
SELECT id, data FROM old_orig_table
UNION ALL
SELECT id, data FROM part_table
;

CREATE TRIGGER orig_table_part_trigger
INSTEAD OF INSERT OR UPDATE OR DELETE on orig_table
FOR EACH ROW
EXECUTE FUNCTION part_v_trigger();

COMMIT;
```
Here is the sample program to move data I used – it’s written in Perl but should be pretty easy for most readers to follow even if not Perl-savvy.
```
#! /bin/perl

use strict;
use DBI;

my $move_rows = qq{
WITH oldkeys AS
(
SELECT id
FROM old_orig_table
LIMIT 10000
)
UPDATE orig_table
SET id = id
WHERE ID IN (SELECT id FROM oldkeys)
};

my $dbh = DBI->connect("dbi:Pg:dbname=tpart;host=/tmp;port=5711",
'','',{AutoCommit => 0, RaiseError => 1, PrintError => 0}
);

my $rows_done;
do
{
$rows_done = $dbh->do($move_rows);
$dbh->commit;
if ($rows_done != 0) # it will be 0e0 which is 0 but true
{
sleep 2;
}
} until $rows_done == 0 || ! $rows_done;
print "done\n";
$dbh->disconnect;
```
Once there are no more rows left in the original table, we can replace the view with the fully partitioned table. In a separate transaction (because it can take some time and it’s not critical) we finally drop the old non-partitioned table.

```
BEGIN;
DROP VIEW orig_table CASCADE;
DROP FUNCTION part_v_trigger();
ALTER SEQUENCE orig_table_id_seq OWNED BY part_table.id;
ALTER TABLE part_table RENAME TO orig_table;
COMMIT;

BEGIN;
DROP TABLE old_orig_table;
COMMIT;
```

Our application should have remained fully functional and blissfully unaware of the changes we have been making under the hood while we were making them.
rkit
PostgreSQL Есть тут боги постгреса? Есть таблица
id, timestamp, event
Какой мне прикрутить индекс, или как нормализовать, чтобы можно было выбрать последний евент для каждого id за вменяемое время? По btree(id, timestamp) должно быть возможно, по идее, но хуй там.
segfault
? PostgreSQL rdbms А есть внятная причина, по которой у нас нет `DELETE CASCADE`, а в место этого предлагается создавать foreign key с флагом `ON DELETE CASCADE` при этом любой `DELETE` будет каскадным?
thefish
цитаты PostgreSQL прекрасное MongoDB "Картина следующая: вот вы тащите миллион записей из таблицы своей mongodb, потом второй миллион из другой таблицы, а потом на клиенте этим вашим джаваскриптом пытаетесь сами, на коленке хоть как-то сделать JOIN.

Во-первых вы гоняете кучу траффика, во-вторых убиваете CPU на клиенте. И главное, в-третьих — вы решаете проблему, с которой в реляционных базах данных блестяще разделались еще в 1980-х годах".
(с)
vt
PostgreSQL говно psql (9.6.3)
ПРЕДУПРЕЖДЕНИЕ: Кодовая страница консоли (866) отличается от основной страницы Windows (1251). 8-битовые (русские) символы могут отображаться некорректно. Подробнее об этом смотрите документацию psql, раздел "Notes for Windows users".

Красноглазым мудакам не лень писать вот эту ахинею, а прекратить пользовать "кодовые страницы" им лень. Что-то я передумываю пользоваться этим.
netneladno
PostgreSQL век живи век учись

postgres=# select * from pg_stat_activity\x\g\x
Expanded display is on.
-[ RECORD 1 ]----+-------------------------------
datid | 13322
datname | postgres
pid | 59116
usesysid | 16386
usename | dboperator
application_name | psql
client_addr |
client_hostname |
client_port | -1
backend_start | 2017-01-27 14:14:06.442956+00
xact_start | 2017-01-27 14:14:34.389409+00
query_start | 2017-01-27 14:14:34.389409+00
state_change | 2017-01-27 14:14:34.389412+00
wait_event_type |
wait_event |
state | active
backend_xid |
backend_xmin | 1778
query | select * from pg_stat_activity

Expanded display is off.
segfault
? MySQL PostgreSQL habrahabr.ru
А почему некоторые выбирают mysql вместо postgresql? Вроде говорили, что у мускуля репликация лучше, но это не совсем правда, судя по статье. Ещё вспоминается невиданная, якобы, скорость движка InnoDB по сравнению с постгре. В установке и администрировании на локалхосте они одинаковы. Зачем кому-то понадобится испльзовать mysql в новом проекте, например?
thefish
PostgreSQL костыли удобне ```
for tbl in `psql -qAt -c "select tablename from pg_tables where schemaname = 'public';" YOUR_DB` ; do psql -c "alter table \"$tbl\" owner to NEW_OWNER" YOUR_DB ; done

for tbl in `psql -qAt -c "select sequence_name from information_schema.sequences where sequence_schema = 'public';" YOUR_DB` ; do psql -c "alter table \"$tbl\" owner to NEW_OWNER" YOUR_DB ; done

for tbl in `psql -qAt -c "select table_name from information_schema.views where table_schema = 'public';" YOUR_DB` ; do psql -c "alter table \"$tbl\" owner to NEW_OWNER" YOUR_DB ; done
```
netneladno
PostgreSQL говно ребята из перконы починили флаш в мускуле еще в 2012 году!
в постгресе сделали шаг к стабильности при чекпоинте в 9.6, в 2016 году
но один хуй стабильно не работает. это пиздец.
лучшая опенсорсная база данных яебал
tosh
PostgreSQL А тут вот поговаривают выходит pgadmin4.

Надеюсь, парни приблизились хоть немного к мускульному SQLYog'у, а то у каждой альтернативной удобной софтины к постгресу сейчас уйма врождённых проблем.

pgsnake.blogspot.ru
tosh
Oracle PostgreSQL техдрама Завязочка: vedomosti.ru
Продолжение: postgresql.org

Оракл канеш свиньи и шлюшки, но я бы на месте постгри удержался от ответных действий: чо позориться, вступая с даунами в перепалку. А откатные говноеды пускай остаются в своём болоте, до них вообще нет дела.