On Sun, 23 Dec 2018 23:06:51 -0800, Mitar wrote:
>On Fri, Dec 21, 2018 at 11:10 PM George Neuner wrote:
>> A materialized view IS exactly such a deliberate cache of results from
>> applying a view. It is a real table that can be monitored for changes
>> using INSERT, UPDATE and/or DELETE trigge
Hi!
On Fri, Dec 21, 2018 at 11:10 PM George Neuner wrote:
> A materialized view IS exactly such a deliberate cache of results from
> applying a view. It is a real table that can be monitored for changes
> using INSERT, UPDATE and/or DELETE triggers.
Are you sure one can use triggers on a materi
Hi!
Currently I am doing:
CREATE TRIGGER some_trigger AFTER UPDATE ON my_table REFERENCING NEW
TABLE AS new_table OLD TABLE AS old_table FOR EACH STATEMENT EXECUTE
FUNCTION my_trigger();
In my trigger I do:
PERFORM * FROM ((TABLE new_table EXCEPT TABLE new_table) UNION ALL
(TABLE new_table EXCE
Hi,
Is there a way to write a code found at
https://www.postgresql.org/docs/9.1/libpq-example.html
Example 2 with the ODBC interface?
Thank you.
Hi!
On Sun, Dec 23, 2018 at 1:00 AM George Neuner wrote:
> A spreadsheet is an order of magnitude simpler to implement than a
> DBMS, but the combination would be an order of magnitude (or more)
> harder. Even object graph databases don't offer spreadsheet
> functionality, and it would be a lot
I have a database with about 1 TB of data, mostly inserts, little
updates and deletes, and I want to setup 2 logical replication for it.
What should be my expectation with the replication?
1. What is the time-window that either of the nodes can be offline?
- Will it survive if the node doing the p
Hi Mark,
It's look very weird.
Can you try something like this (check that you have enough disk space for
second copy of common_student before):
create table test_table AS SELECT * from common_student;
Vacuum analyze test_table;
explain analyze select * from test_table where school_id = 36;
drop
On Fri, 21 Dec 2018 23:41:16 -0800, Mitar wrote:
>Hi!
>
>On Fri, Dec 21, 2018 at 11:10 PM George Neuner wrote:
>> A materialized view IS exactly such a deliberate cache of results from
>> applying a view. It is a real table that can be monitored for changes
>> using INSERT, UPDATE and/or DELETE
