Table of Contents
- Alternative variants
- Standalone usage
- Usage with Meltano
- Looking for help?
- Repository: https://github.com/transferwise/pipelinewise-target-postgres
- Maintainer: Wise
- Maintenance status: Active
target-postgres are available. This document describes the
Alternative variants are:
Install the package using pip:
pip install pipelinewise-target-postgres
For additional instructions, refer to the README in the repository.
Usage with Meltano
meltano add loader target-postgres --variant transferwise
For additional instructions, refer to the
Meltano-specific documentation for
PostgreSQL database name
Name of the schema where the tables will be created. If
schema_mapping is not defined then every stream sent by the tap is loaded into this schema.
Maximum number of rows in each batch. At the end of each batch, the rows in the batch are loaded into Postgres.
Flush and load every stream into Postgres when one batch is full. Warning: This may trigger the COPY command to use files with low number of records.
The number of threads used to flush tables. 0 will create a thread for each stream, up to parallelism_max. -1 will create a thread for each CPU core. Any other positive number will create that number of threads, up to parallelism_max.
Max number of parallel threads to use when flushing tables.
Grant USAGE privilege on newly created schemas and grant SELECT privilege on newly created tables to a specific role or a list of roles. If
schema_mapping is not defined then every stream sent by the tap is granted accordingly.
Useful if you want to load multiple streams from one tap to multiple Postgres schemas. If the tap sends the
<schema_name>-<table_name> format then this option overwrites the
default_target_schema value. Note, that using
schema_mapping you can overwrite the
default_target_schema_select_permission value to grant SELECT permissions to different groups per schemas or optionally you can create indices automatically for the replicated tables.
Metadata columns add extra row level information about data ingestions, (i.e. when was the row read in source, when was inserted or deleted in postgres etc.) Metadata columns are creating automatically by adding extra columns to the tables with a column prefix
_SDC_. The column names are following the stitch naming conventions documented at https://www.stitchdata.com/docs/data-structure/integration-schemas#sdc-columns. Enabling metadata columns will flag the deleted rows by setting the
_SDC_DELETED_AT metadata column. Without the
add_metadata_columns option the deleted rows from singer taps will not be recongisable in Postgres.
hard_delete option is true then DELETE SQL commands will be performed in Postgres to delete rows in tables. It’s achieved by continuously checking the
_SDC_DELETED_AT metadata column sent by the singer tap. Due to deleting rows requires metadata columns,
hard_delete option automatically enables the
add_metadata_columns option as well.
Object type RECORD items from taps can be transformed to flattened columns by creating columns automatically. When value is 0 (default) then flattening functionality is turned off.
Log based and Incremental replications on tables with no Primary Key cause duplicates when merging UPDATE events. When set to true, stop loading data if no Primary Key is defined.
Validate every single record message to the corresponding JSON schema. This option is disabled by default and invalid RECORD messages will fail only at load time by Postgres. Enabling this option will detect invalid records earlier but could cause performance degradation.
(Default: platform-dependent) Directory of temporary CSV files with RECORD messages.
Looking for help?
If you're having trouble getting
target-postgres to work by itself or with
Meltano, look for an
existing issue in its repository, file a new issue,
join the Meltano Slack community
and ask for help in the