termine what is going on, EXPLAIN (ANALYZE, BUFFERS) output
would be useful.
Yours,
Laurenz Albe
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
hen I run a select on pg_settings with these two users I recieve different
> results.
That is intentional, because some settings should only be
visible for superusers, for example everything that has to
do with the operating system (location of configuration file
or socket directories).
Yours,
La
output TAR file will be compressed, it has
nothing to do with the data transfered from the server.
If you want to compress the data sent over the network, use
pg_basebackup over an SSL connection with SSL compression enabled.
Yours,
Laurenz Albe
--
Sent via pgsql-general mailing list (pgsql-general
re you trying to achieve?
Yours,
Laurenz Albe
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
NVOICE_NUM%TYPE,
> TXN_CNT NUMBER
>);
You can create a composite type in PostgreSQL:
CREATE TYPE complex AS (r integer, i integer);
>TYPE INV_LINES_T IS TABLE OF INV_LINES_RT;
You would use an array in this case:
DECLARE
carr complex[];
Yours,
Laurenz Albe
--
Sent v
Brahmam Eswar wrote:
> How to migrate the Oracle collection types ( IsTableOF, IsRecord) to postgres.
Are you talking about table definitions or PL/SQL code?
Yours,
Laurenz Albe
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
h
information.
If there is nothing suspicious in the log, and hot standby is enabled,
and the standby is configured appropriately, it could be that a conflicting
query on the standby block WAL application for a while.
Yours,
Laurenz Albe
--
Sent via pgsql-general mailing list (pgsql-general@po
hat brings the "materialized view"
up to date.
Yours,
Laurenz Albe
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
anyone help?
Based on my experience with oracle_fdw, I would change the function declaration
in tds_fdw.h to
extern PGDLLEXPORT Datum tds_fdw_handler(PG_FUNCTION_ARGS);
Yours,
Laurenz Albe
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
r is indeed surprising.
I *assume* that it refers to numbers eliminate from the merge join result,
but that's only guessing.
> The materialize returns 184791 rows. This one I understand: There are 6
> non-null distinct values of arbeitsvolumen in facttable_kon_eh, and each
> appears 369
591)
> Index Cond: ((m.chrom = 22) AND (m.basepos >= s.startbase) AND
(m.basepos <= s.endbase))
I think your biggest problem is the join condition
on m.basepos between s.startbase and s.endbase
That forces a nested loop join, which cannot be performed efficiently.
Yours,
La
base parameters identical?
Also, to have PostgreSQL inline the function, which would be good
for performance, it should be declared IMMUTABLE.
Yours,
Laurenz Albe
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
4) 5.4.0 20160609, 64-bit
PostgreSQL did not complain about an index being zeroed, it just
says it can't find a certain page (which probably never existed).
The missing CLOG entries are probably just an effect of data
corruption - a tuple that contains a non-existing transaction
number.
same
OID
in the second database.
I'd restore the large objects and manually fix all collisions
(import the problematic large objects with a different OID and adjust
the referencing tables accordingly).
This might prove difficult if there are a lot of collisions, but I don't think
that the
on_target is 0.9, spending 0.9 * 3600 = 3240
seconds
per hour doing checkpoints would be normal.
The whole point of this parameter is to spread checkpoints across
a longer time to avoid I/O spikes.
Yours,
Laurenz Albe
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To mak
15 matches
Mail list logo
