Re: Copy Bulk Ignore Duplicated

Hi Adrian, Yes, that's the problem! I'm testing now the pg_bulkload but I'm facing some issues to install it on Postgresql 9.4. Leandro Guimarães On Mon, Jun 17, 2019 at 1:22 PM Adrian Klaver wrote: > On 6/17/19 9:06 AM, Leandro Guimarães wrote: > Please reply to list also. > Ccing lis

Re: checkpoints taking much longer than expected

On 2019-06-16 12:25:58 -0400, Jeff Janes wrote: > Right, but true only because they were "checkpoint starting: immediate". > Otherwise the reported write time includes intentional sleeps added to > honor the checkpoint_completion_target. A bit confusing to report it that > way, I think. +1 It's

Re: Copy Bulk Ignore Duplicated

On 6/17/19 10:04 AM, Leandro Guimarães wrote: Hi Adrian,    Yes, that's the problem!    I'm testing now the pg_bulkload but I'm facing some issues to install it on Postgresql 9.4. The issues would be? Leandro Guimarães -- Adrian Klaver adrian.kla...@aklaver.com

Re: Copy Bulk Ignore Duplicated

I've installed all dependencies, but when I try to "make install" in pg_bulkload folder if have some errors like this: In file included from pgut/pgut.h:24:0, from pgut/pgut-fe.h:13, from pg_bulkload.c:17: /usr/include/postgresql/internal/pqexpbuffer.h:149:13: err

perf tuning for 28 cores and 252GB RAM

I am using a Postgres instance in an HPC cluster, where they have generously given me an entire node. This means I have 28 cores and 252GB RAM. I have to assume that the very conservative default settings for things like buffers and max working memory are too small here. We have about 20 billion r

psql UPDATE field [tab] expands to DEFAULT?

Hi. If I'm using psql, and type for example: UPDATE my_table SET my_field (with a trailing space) and then hit Tab, it will expand that to an =, and then another tab will expand to DEFAULT, so that I then have: UPDATE my_table SET my_field = DEFAULT If I'm tabbing out in this situation, it's g

Re: Copy Bulk Ignore Duplicated

On 6/17/19 12:01 PM, Leandro Guimarães wrote: I've installed all dependencies, but when I try to "make install" in pg_bulkload folder if have some errors like this: In file included from pgut/pgut.h:24:0,                  from pgut/pgut-fe.h:13,                  from pg_bulkload.c:17: /usr/in

Re: psql UPDATE field [tab] expands to DEFAULT?

On 6/17/19 3:03 PM, Ken Tanzer wrote: Hi.  If I'm using psql, and type for example: UPDATE my_table SET my_field (with a trailing space) and then hit Tab, it will expand that to an =, and then another tab will expand to DEFAULT, so that I then have: UPDATE my_table SET my_field = DEFAULT If

Re: psql UPDATE field [tab] expands to DEFAULT?

On Mon, Jun 17, 2019 at 4:24 PM Adrian Klaver wrote: > On 6/17/19 3:03 PM, Ken Tanzer wrote: > > > > So I'm curious if this is intended behavior, if it's considered useful, > > and/or if it's a placeholder for something in the future that will be > > useful. Also, is this new, as I've never noti

Re: perf tuning for 28 cores and 252GB RAM

On Mon, Jun 17, 2019 at 4:51 PM Michael Curry wrote: > I am using a Postgres instance in an HPC cluster, where they have > generously given me an entire node. This means I have 28 cores and 252GB > RAM. I have to assume that the very conservative default settings for > things like buffers and max

Inserts restricted to a trigger

Is there are way to restrict direct access to a table for inserts but allow a trigger on another table to perform an insert for that user? I'm trying to implement an audit table without allowing user tampering with the audit information. Thanks in advance, Miles Elam

Re: psql UPDATE field [tab] expands to DEFAULT?

On Tue, 18 Jun 2019 at 09:34, Ken Tanzer wrote: > On Mon, Jun 17, 2019 at 4:24 PM Adrian Klaver > wrote: > >> On 6/17/19 3:03 PM, Ken Tanzer wrote: >> > >> > So I'm curious if this is intended behavior, if it's considered useful, >> > and/or if it's a placeholder for something in the future that

Re: psql UPDATE field [tab] expands to DEFAULT?

On 6/17/19 4:33 PM, Ken Tanzer wrote: On Mon, Jun 17, 2019 at 4:24 PM Adrian Klaver > wrote: On 6/17/19 3:03 PM, Ken Tanzer wrote: > > So I'm curious if this is intended behavior, if it's considered useful, > and/or if it's a placeholder f

Re: psql UPDATE field [tab] expands to DEFAULT?

On Mon, Jun 17, 2019 at 6:03 PM Ken Tanzer wrote: > Hi. If I'm using psql, and type for example: > > UPDATE my_table SET my_field > (with a trailing space) > > and then hit Tab, it will expand that to an =, and then another tab will > expand to DEFAULT, so that I then have: > > UPDATE my_table S

Re: Inserts restricted to a trigger

On 6/17/19 4:54 PM, Miles Elam wrote: Is there are way to restrict direct access to a table for inserts but allow a trigger on another table to perform an insert for that user? I'm trying to implement an audit table without allowing user tampering with the audit information. Would the below

Re: psql UPDATE field [tab] expands to DEFAULT?

On Mon, Jun 17, 2019 at 8:23 PM Adrian Klaver wrote: > On 6/17/19 4:33 PM, Ken Tanzer wrote: > > > > Thanks Adrian, though I wasn't really seeking tips for column names. I > > was instead trying to understand whether this particular tab expansion > > was intentional and considered useful, and if

Re: psql UPDATE field [tab] expands to DEFAULT?

Tim Cross writes: > On Tue, 18 Jun 2019 at 09:34, Ken Tanzer wrote: >> Thanks Adrian, though I wasn't really seeking tips for column names. I >> was instead trying to understand whether this particular tab expansion was >> intentional and considered useful, and if so what that usefulness was, >>

Re: Inserts restricted to a trigger

Adrian Klaver wrote: > On 6/17/19 4:54 PM, Miles Elam wrote: > > Is there are way to restrict direct access to a table for inserts but > > allow a trigger on another table to perform an insert for that user? > > > > I'm trying to implement an audit table without allowing user tampering > > with t

Re: psql UPDATE field [tab] expands to DEFAULT?

On Tue, 18 Jun 2019 at 10:39, Tom Lane wrote: > Tim Cross writes: > > On Tue, 18 Jun 2019 at 09:34, Ken Tanzer wrote: > >> Thanks Adrian, though I wasn't really seeking tips for column names. I > >> was instead trying to understand whether this particular tab expansion > was > >> intentional a

Re: Async client libraries - not worth it?

On Mon, 17 Jun 2019 at 01:34, Rob Nikander wrote: > Hi, > > I’m writing a new web app, and I’ve been experimenting with some async DB > access libraries [1]. I also see some discussion online about a future Java > standard to replace or supplement JDBC with an async API. > > While I understand th

Re: Async client libraries - not worth it?

> On Jun 17, 2019, at 1:12 PM, Dave Cramer wrote: > > https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=db > > > Seems to be worth it. > > Now it appears that ADBA is going to die on the vine, R2DBC an

Re: bug regclass::oid

hi again here is my query *select A.table_name as "table_name",A.domain_name as "domain",* * format_type(c.atttypid, c.atttypmod) AS data_type ,A.column_name as "column_name",* * A.is_nullable as "nullable",A.column_default as "default"* * from information_schema.columns A inner join pg_a

Re: checkpoints taking much longer than expected

On Sun, Jun 16, 2019 at 8:57 PM Alvaro Herrera wrote: > On 2019-Jun-14, Peter J. Holzer wrote: > > > There was a discussion about ZFS' COW behaviour and PostgreSQL reusing > > WAL files not being a good combination about a year ago: > > > https://www.postgresql.org/message-id/flat/CACukRjO7DJvub8

Re: Async client libraries - not worth it?

On Mon, 17 Jun 2019 at 07:35, Rob Nikander wrote: > > > On Jun 17, 2019, at 1:12 PM, Dave Cramer wrote: > > https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=db > > Seems to be worth it. > > Now it appears that ADBA is going to die on the vine, R2DBC and vertx seem > to be pret

Re: Async client libraries - not worth it?

> On Jun 17, 2019, at 3:57 PM, Dave Cramer wrote: > […] Postgres can pipeline requests if the client is written correctly so it > is conceivable that this would be much faster. Can the JDBC driver do this? I don’t see it documented anywhere.

Re: Async client libraries - not worth it?

On Mon, 17 Jun 2019 at 09:43, Rob Nikander wrote: > > > > On Jun 17, 2019, at 3:57 PM, Dave Cramer wrote: > > […] Postgres can pipeline requests if the client is written correctly so > it is conceivable that this would be much faster. > > Can the JDBC driver do this? I don’t see it documented an

Re: bug regclass::oid

On 6/17/19 1:58 AM, John Mikel wrote: hi again here is my query *select   A.table_name  as "table_name",A.domain_name as "domain",* * format_type(c.atttypid, c.atttypmod)  AS data_type ,A.column_name as "column_name",* *  A.is_nullable as "nullable",A.column_default as "default"* *  from inf

Re: Copy Bulk Ignore Duplicated

Hi Adrian, You are right, these fields are in CHECK CONSTRAiNTS and they are not formally defined as Primary Keys. Thanks! Leandro Guimarães On Sat, Jun 15, 2019 at 10:45 AM Adrian Klaver wrote: > On 6/14/19 7:24 PM, Leandro Guimarães wrote: > > Hi Tim, thanks for you answer! > > > > The

Re: Copy Bulk Ignore Duplicated

On 6/17/19 8:14 AM, Leandro Guimarães wrote: Hi Adrian,    You are right, these fields are in CHECK CONSTRAiNTS and they are not formally defined as Primary Keys. Alright. Two things: 1) If you are are thinking of them as keys, why not make them a PK or a UNIQUE index? 2) Still not clear

psql timeout option

Hello! Does the psql command have a timeout option for network connections?

Re: psql timeout option

On 6/17/19 8:59 AM, Jesús Gómez wrote: Hello! Does the psql command have a timeout option for network connections? Something like below? If not you will need to be more specific https://www.postgresql.org/docs/11/app-psql.html From within psql: \c or \connect \c "host=localhost port=5432

Re: Copy Bulk Ignore Duplicated

On 6/17/19 9:06 AM, Leandro Guimarães wrote: Please reply to list also. Ccing list. Ugh My bad again. They are UNIQUE: CONSTRAINT unique_const_value_20190501_45 UNIQUE (customer_id, date_time, indicator_id, element_id), I've made a mistake typing "check constraint" before because these are p

Re: Copy Bulk Ignore Duplicated

On 6/17/19 9:22 AM, Adrian Klaver wrote: On 6/17/19 9:06 AM, Leandro Guimarães wrote: Please reply to list also. Ccing list. Ugh My bad again. They are UNIQUE: CONSTRAINT unique_const_value_20190501_45 UNIQUE (customer_id, date_time, indicator_id, element_id), I've made a mistake typing "che