Re: [GENERAL] Load a csv to remote postgresql database

On 3/1/2017 10:01 PM, priyanka raghav wrote: I am trying to load a csv file of approx 500mb to remote postgres database. Earlier when the app server and db server were co-located, COPY command was working fine but ever since the db server is moved to a different box, the command is failing. I und

Re: [GENERAL] Load a csv to remote postgresql database

Hi 2017-03-02 7:01 GMT+01:00 priyanka raghav : > Hi, > > I am trying to load a csv file of approx 500mb to remote postgres > database. Earlier when the app server and db server were co-located, > COPY command was working fine but ever since the db server is moved to > a different box, the command

[GENERAL] Load a csv to remote postgresql database

Hi, I am trying to load a csv file of approx 500mb to remote postgres database. Earlier when the app server and db server were co-located, COPY command was working fine but ever since the db server is moved to a different box, the command is failing. I understand that COPY command searches the fil

Re: [GENERAL] Understanding pg_last_xlog_receive_location

On Thu, Mar 2, 2017 at 5:53 AM, Zach Walton wrote: > I was able to test 9.4.11 and am seeing the same behavior: > > postgres=# SELECT pg_is_in_recovery(), pg_last_xlog_receive_location(), > pg_last_xlog_replay_location(); > pg_is_in_recovery | pg_last_xlog_receive_location | > pg_last_xlog_replay

Re: [GENERAL] Understanding pg_last_xlog_receive_location

I was able to test 9.4.11 and am seeing the same behavior: postgres=# SELECT pg_is_in_recovery(), pg_last_xlog_receive_location(), pg_last_xlog_replay_location(); pg_is_in_recovery | pg_last_xlog_receive_location | pg_last_xlog_replay_location ---+---+-

Re: [GENERAL] Re: Causeless CPU load waves in backend, on windows, 9.5.5 (EDB binary).

27.02.2017 10:08, I wrote: [...] So, what I've observed is that Wait* functions _usually_ go to sleep nicely when the state is not signalled, but _sometimes_, depending on unknown criteria, it can choose to instead do a busy-loop wait or something CPU-expensive. Maybe it tries to optimize the del

Re: [GENERAL] Understanding pg_last_xlog_receive_location

Thanks. We have some patches on the 9.4.5 code base (not in the replication path). I'll work on porting those to 9.4.11 and will report back to the thread.

Re: [GENERAL] disk writes within a transaction

On Feb 17, 2017, at 4:05 PM, Jeff Janes wrote: > It will probably be easier to refactor the code than to quantify just how > much damage it does. Thanks for all the info. It looks like this is something worth prioritizing because of the effects on indexes. We had discussed a fix and pointed

Re: [GENERAL] appropriate column for storing ipv4 address

> On Mar 1, 2017, at 8:39 AM, jonathan vanasco wrote: > > > I have to store/search some IP data in Postgres 9.6 and am second-guessing my > storage options. > > > The types of searching I'm doing: [...] > > 2. on tracked_ip_block, i search/join against the tracked_ip_address to >

Re: [GENERAL] appropriate column for storing ipv4 address

On 03/01/2017 08:39 AM, jonathan vanasco wrote: I have to store/search some IP data in Postgres 9.6 and am second-guessing my storage options. Would anyone mind giving this a quick look for me? Right now I have two tables, and am just using cidr for both: Hi Jonathan, CIDR seems like a bet

[GENERAL] appropriate column for storing ipv4 address

I have to store/search some IP data in Postgres 9.6 and am second-guessing my storage options. Would anyone mind giving this a quick look for me? Right now I have two tables, and am just using cidr for both: create table tracked_ip_address ( id SERIAL primary key,

Re: [GENERAL] is (not) distinct from

Adrian Klaver writes: > Where I am going with this, is that it is not clear to me how you are > matching the two sets of records to determine whether they are different > or not. He's not. The query is forming the cartesian product of the two tables and then dropping join rows where the tables

Re: [GENERAL] is (not) distinct from

On 03/01/2017 12:15 AM, Johann Spies wrote: On 28 February 2017 at 17:06, Adrian Klaver mailto:adrian.kla...@aklaver.com>> wrote: I have not worked through all this but at first glance I suspect: select distinct b.* from b ... is distinct from ... constitutes a double negativ

Re: [GENERAL] ERROR: functions in index expression must be marked IMMUTABLE

On 01.03.2017 14:40, Geoff Winkless wrote: On 1 March 2017 at 13:36, Sven R. Kunze >wrote: On 28.02.2017 17:50, David G. Johnston wrote: Supposedly one could provide a version of to_date that accepts a locale in which to interpret names in the input data - or

Re: [GENERAL] ERROR: functions in index expression must be marked IMMUTABLE

On 1 March 2017 at 13:36, Sven R. Kunze wrote: > On 28.02.2017 17:50, David G. Johnston wrote: > > Supposedly one could provide a version of to_date that accepts a locale in > which to interpret names in the input data - or extend the format string > with some kind of "{locale=en_US}" syntax to a

Re: [GENERAL] ERROR: functions in index expression must be marked IMMUTABLE

On 28.02.2017 17:50, David G. Johnston wrote: ​That would seem to be it. cache_locale_time() at the top of DCH_to_char which is in the call stack of the shared parsing code for both to_date and to_timestamp. ​https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/utils/adt/f

Re: [GENERAL] is (not) distinct from

On 28 February 2017 at 17:06, Adrian Klaver wrote: > > I have not worked through all this but at first glance I suspect: > > select distinct b.* from b ... > > is distinct from ... > > constitutes a double negative. > > What happens if you eliminate the first distinct? > > > > Thanks Adrian, The