Re: [PERFORM] pg_restore seems very slow

2016-06-15 Thread Adam Scott
The "simple" case may be anti-virus or firewall blocking feeding into the database. Be sure to check windows system logs for any unusual messages. Check the postgres log (usually in PGDATA/pg_logs) For seeing disk I/O on Win7 check out

Re: [PERFORM] pg_restore seems very slow

2016-06-15 Thread Adrian Myers
Hi David, Thank you for your reply. Yes, there is quite a lot of feedback in the terminal. I can see a small flurry of table operations followed by hours of table contents being printed, presumably as they are inserted. I didn't use the --verbose option, but it seems to be echoing everything it

Re: [PERFORM] pg_restore seems very slow

2016-06-15 Thread David G. Johnston
On Wed, Jun 15, 2016 at 6:00 PM, Adrian Myers wrote: > This is my first post to the mailing list, so I apologize for any > etiquette issues. > > I have a few databases that I am trying to move from one system to > another. Both systems are running Windows 7 and Postgres

[PERFORM] pg_restore seems very slow

2016-06-15 Thread Adrian Myers
This is my first post to the mailing list, so I apologize for any etiquette issues. I have a few databases that I am trying to move from one system to another. Both systems are running Windows 7 and Postgres 8.4, and they are pretty powerful machines (40-core Xeon workstations with decent

Re: [PERFORM] Indexes for hashes

2016-06-15 Thread Jeff Janes
On Wed, Jun 15, 2016 at 6:16 AM, k...@rice.edu wrote: > On Wed, Jun 15, 2016 at 03:09:04PM +0200, Ivan Voras wrote: >> On 15 June 2016 at 15:03, k...@rice.edu wrote: >> >> >> I don't suppose there's an effort in progress to make hash indexes use WAL? >> :D > > Hi

Re: [PERFORM] Indexes for hashes

2016-06-15 Thread k...@rice.edu
On Wed, Jun 15, 2016 at 04:20:46PM +0200, Ivan Voras wrote: > Hi, > > Just for testing... is there a fast (i.e. written in C) crc32 or a similar > small hash function for PostgreSQL? > Hi Ivan, Here is an extension that provides a number of different hash functions, including a version of the

Re: [PERFORM] Indexes for hashes

2016-06-15 Thread Joshua D. Drake
On 06/15/2016 07:20 AM, Ivan Voras wrote: Hi, Just for testing... is there a fast (i.e. written in C) crc32 or a similar small hash function for PostgreSQL? https://www.postgresql.org/docs/9.5/static/pgcrypto.html We also have a builtin md5(). JD -- Command Prompt, Inc.

Re: [PERFORM] Indexes for hashes

2016-06-15 Thread Ivan Voras
Hi, Just for testing... is there a fast (i.e. written in C) crc32 or a similar small hash function for PostgreSQL? On 15 June 2016 at 16:00, Ivan Voras wrote: > Hi, > > This idea is similar to the substring one, and while it does give > excellent performance and small size,

Re: [PERFORM] Indexes for hashes

2016-06-15 Thread Ivan Voras
Hi, This idea is similar to the substring one, and while it does give excellent performance and small size, it requires application code modifications, so it's out. On 15 June 2016 at 15:58, julyanto SUTANDANG wrote: > Hi Ivan, > > How about using crc32 ? and then index

Re: [PERFORM] Indexes for hashes

2016-06-15 Thread julyanto SUTANDANG
Hi Ivan, How about using crc32 ? and then index the integer as the result of crc32 function? you can split the hash into 2 part and do crc32 2x ? and then create composite index on both integer (the crc32 result) instead of using 64 char, you only employ 2 integer as index key. Regards, Jul On

Re: [PERFORM] Indexes for hashes

2016-06-15 Thread Ivan Voras
Hi, I understand your idea, and have also been thinking about it. Basically, existing applications would need to be modified, however slightly, and that wouldn't be good. On 15 June 2016 at 15:38, hubert depesz lubaczewski wrote: > On Wed, Jun 15, 2016 at 11:34:18AM

Re: [PERFORM] Indexes for hashes

2016-06-15 Thread hubert depesz lubaczewski
On Wed, Jun 15, 2016 at 11:34:18AM +0200, Ivan Voras wrote: > I have an application which stores a large amounts of hex-encoded hash > strings (nearly 100 GB of them), which means: Why do you keep them hex encoded, and not use bytea? I made a sample table with 1 million rows, looking like this:

Re: [PERFORM] Indexes for hashes

2016-06-15 Thread k...@rice.edu
On Wed, Jun 15, 2016 at 03:09:04PM +0200, Ivan Voras wrote: > On 15 June 2016 at 15:03, k...@rice.edu wrote: > > > On Wed, Jun 15, 2016 at 11:34:18AM +0200, Ivan Voras wrote: > > > Hi, > > > > > > I have an application which stores a large amounts of hex-encoded hash > > > strings

Re: [PERFORM] Indexes for hashes

2016-06-15 Thread Ivan Voras
On 15 June 2016 at 15:03, k...@rice.edu wrote: > On Wed, Jun 15, 2016 at 11:34:18AM +0200, Ivan Voras wrote: > > Hi, > > > > I have an application which stores a large amounts of hex-encoded hash > > strings (nearly 100 GB of them), which means: > > > >- The number of distinct

Re: [PERFORM] Indexes for hashes

2016-06-15 Thread k...@rice.edu
On Wed, Jun 15, 2016 at 11:34:18AM +0200, Ivan Voras wrote: > Hi, > > I have an application which stores a large amounts of hex-encoded hash > strings (nearly 100 GB of them), which means: > >- The number of distinct characters (alphabet) is limited to 16 >- Each string is of the same

Re: [PERFORM] Indexes for hashes

2016-06-15 Thread Torsten Zuehlsdorff
Hello Ivan, I have an application which stores a large amounts of hex-encoded hash strings (nearly 100 GB of them), which means: * The number of distinct characters (alphabet) is limited to 16 * Each string is of the same length, 64 characters * The strings are essentially random

Re: [PERFORM] Clarification on using pg_upgrade

2016-06-15 Thread Glyn Astill
- Original Message - > From: Tory M Blue > To: Jim Nasby > Cc: "pgsql-performance@postgresql.org" > Sent: Tuesday, 14 June 2016, 22:08 > Subject: Re: [PERFORM] Clarification on using pg_upgrade > > Right,