Re: [GENERAL] Breaking up a PostgreSQL COPY command into chunks?

On Fri, Nov 8, 2013 at 5:09 AM, Victor Hooi wrote: > They think that it might be limited by the network, and how fast the > PostgreSQL server can push the data across the internet. (The Postgres > server and the box running the query are connected over the internet). You previously said you had 6

Re: [GENERAL] Breaking up a PostgreSQL COPY command into chunks?

Hi, Aha, I spoke to the somebody, apparently we've actually got those values set to 15 minutes currently... They think that it might be limited by the network, and how fast the PostgreSQL server can push the data across the internet. (The Postgres server and the box running the query are connecte

Re: [GENERAL] Breaking up a PostgreSQL COPY command into chunks?

Hi, Hmm, ok, I'll pass that onto our DBA/operations guys, and see if that helps. Do these settings still work if you only have a single Postgres instance? (I'll need to check out setup). So my understanding is that the default is 30 seconds ( http://www.postgresql.org/docs/9.3/static/runtime-con

Re: [GENERAL] Breaking up a PostgreSQL COPY command into chunks?

Try this, max_standby_archive_delay = 600s# max delay before canceling queries # when reading WAL from archive; # -1 allows indefinite delay max_standby_streaming_delay = 600s # max delay before canceling

[GENERAL] Breaking up a PostgreSQL COPY command into chunks?

Hi, We're using psycopg2 with COPY to dump CSV output from a large query. The actual SELECT query itself is large (both in number of records/columns, and also in width of values in columns), but still completes in around under a minute on the server. However, if you then use a COPY with it, it w

Re: [GENERAL] Is it advisable to pg_upgrade directly from 9.0 to 9.3?

On 11/07/2013 11:07 AM, Greg Burek wrote: On Wed, Nov 6, 2013 at 4:36 AM, Leonardo Carneiro mailto:chesterma...@gmail.com>> wrote: I don't think that there will be too much trouble, as long as you follow every changelog tip (9.0->9.1, 9.1->9.2 and 9.2->9.3) What if we don't follow the

Re: [GENERAL] Curious question about physical files to store database

On Tue, Nov 05, 2013 at 10:42:36PM +0800, Patrick Dung wrote: > I have seen some databases product that allocate small number of large files. > > Please correct me if I am wrong: > > MySQL with InnoDB Actually, InnoDB has a file-per-table mode which I tend to prefer. It means that when I drop a

Re: [GENERAL] Is it advisable to pg_upgrade directly from 9.0 to 9.3?

On Wed, Nov 6, 2013 at 4:36 AM, Leonardo Carneiro wrote: > I don't think that there will be too much trouble, as long as you follow > every changelog tip (9.0->9.1, 9.1->9.2 and 9.2->9.3) > > What if we don't follow the changelog tip? In this case, we have only the 9.0 and 9.3 binaries installed a

Re: [GENERAL] problem with partitioned table and indexed json field

I wrote: > It looks like the problem is we're building a MergeAppend plan and not > getting the targetlist for the MergeAppend node right. Found it --- simple oversight in building optimized min/max plans. If you need a patch now, see http://git.postgresql.org/gitweb/?p=postgresql.git;a=patch;h=5d

Re: [GENERAL] After upgrade to 9.3, streaming replication fails to start--SOLVED

On 11/6/13, 12:26 PM, Jeff Ross wrote: On 11/6/13, 11:32 AM, Jeff Janes wrote: On Wed, Nov 6, 2013 at 9:40 AM, Jeff Ross > wrote: _postgresql@nirvana:/var/postgresql $ cat start_hot_standby.sh #!/bin/sh backup_label=wykids_`date +%Y-%m-%d` #remove any

Re: [GENERAL] problem with partitioned table and indexed json field

Raphael Bauduin writes: > The query is also problematic here, because it returns the full json, and > not only the data I selected in the json. Doh, right, you mentioned that in the original bug report, and now that I'm paying a bit more attention I see it too. I was looking for some sort of err

Re: [GENERAL] problem with partitioned table and indexed json field

The query is also problematic here, because it returns the full json, and not only the data I selected in the json. Below, it should return only '_id', and not the whole json stored in event: test3=> select max(event->>'_id') from events where event is not null; max -

Re: [GENERAL] problem with partitioned table and indexed json field

Raphael Bauduin writes: > I have narrowed it a bit. It happens when I create said index on an empty > field. Here's the scenario to reproduce it: Thanks, I've reproduced the problem here. The query still seems to run OK, it's just EXPLAIN that's falling over --- do you see the same?

Re: [GENERAL] problem with partitioned table and indexed json field

Correction: It happens when I create said index on an empty *table*. Raph On Thu, Nov 7, 2013 at 11:10 AM, Raphael Bauduin wrote: > Hi, > > I have narrowed it a bit. It happens when I create said index on an empty > field. Here's the scenario to reproduce it: > > Let me know if you need more i

Re: [GENERAL] problem with partitioned table and indexed json field

Hi, I have narrowed it a bit. It happens when I create said index on an empty field. Here's the scenario to reproduce it: Let me know if you need more info Cheers Raph create table events(id SERIAL, timestamp timestamp, event json); create table event