Re: [GENERAL] pg_dump slower than pg_restore

2014-07-04 Thread Tom Lane
David Wall writes: > On 7/4/2014 7:19 AM, Tom Lane wrote: >> You haven't given us much info about the contents of this database. >> Are there a lot of tables? functions? large objects? How many is >> "a lot", if so? > There are only 32 table, no functions, but mostly large objects. Not > sure h

Re: [GENERAL] Random-looking primary keys in the range 100000..999999

2014-07-04 Thread Gavin Flower
On 05/07/14 15:48, Gavin Flower wrote: On 05/07/14 01:24, Kynn Jones wrote: I'm looking for a way to implement pseudorandom primary keys in the range 10..99. The randomization scheme does not need to be cryptographically strong. As long as it is not easy to figure out in a few minute

Re: [GENERAL] Random-looking primary keys in the range 100000..999999

2014-07-04 Thread Gavin Flower
On 05/07/14 01:24, Kynn Jones wrote: I'm looking for a way to implement pseudorandom primary keys in the range 10..99. The randomization scheme does not need to be cryptographically strong. As long as it is not easy to figure out in a few minutes it's good enough. My starting point

[GENERAL] memory leak while trying to update/alter column in postgresql

2014-07-04 Thread Madhurima Das
I am trying to update/alter two columns-comment and id in a table called xxx using postgresql. Though the compiler does not show any errors but Valgrind gives major memory leak errors. The code is: int main() { PGconn *conn; PGresult *res; int i=0,nFields=0,row=0,col=0; conn = PQconnectdb

Re: Re : [GENERAL] Query "top 10 and others"

2014-07-04 Thread David Johnston
> > > with QRY as (select C1.country, C1.state, sum(C1.population) > > from places C1 > > group by 1, 2 > >order by 3 DESC > > limit 10) > > > > select * from QRY > > union > > select 'others' as "country", '' as "state", sum(population) > > from places > > where not exists (select 1 f

Re : [GENERAL] Query "top 10 and others"

2014-07-04 Thread Edson Richter
Would you please provide an example, even hypothetical?  Atenciosamente,Edson Richter -- Mensagem original --De: David G Johnston Data: 04/07/2014 19h22Para: pgsql-general@postgresql.org;Assunto:Re: [GENERAL] Query "top 10 and others"Edson Richter wrote > I would like to construct a query,

Re: [GENERAL] Query "top 10 and others"

2014-07-04 Thread David G Johnston
Edson Richter wrote > I would like to construct a query, to be used in graphics (Pie Chart, to > be more precise), and to avoid having 500 slices, I would like to make a > query that returns the top ten, and then all the rest summed. > > I know I can do it by using some repetition, like: > > a) A

[GENERAL] Query "top 10 and others"

2014-07-04 Thread Edson Richter
I would like to construct a query, to be used in graphics (Pie Chart, to be more precise), and to avoid having 500 slices, I would like to make a query that returns the top ten, and then all the rest summed. I know I can do it by using some repetition, like: a) Assume "places" table with popula

Re: [GENERAL] pg_dump slower than pg_restore

2014-07-04 Thread Bosco Rama
On 07/03/14 22:51, David Wall wrote: > > On 7/3/2014 11:47 AM, Eduardo Morras wrote: >> No, there's nothing wrong. All transparent compressed objects stored >> in database, toast, lo, etc.. is transparently decompressed while >> pg_dump access them and then you gzip it again. I don't know why it

[GENERAL] index contains unexpected zero page at block error

2014-07-04 Thread François Beausoleil
Hi, I ran a query on the slave and got the error message in the subject. I rebuilt the slave two days ago on ZFS (with compression). I’m wondering how that unexpected zero page happened in the first place. Master: Linux kalanchoe 3.2.0-58-generic #88-Ubuntu SMP Tue Dec 3 17:37:58 UTC 2013 x86_

Re: [GENERAL] pg_dump slower than pg_restore

2014-07-04 Thread Bosco Rama
On 07/03/14 22:51, David Wall wrote: > > It just seems odd that pg_dump is slower than pg_restore to me. Most > grumblings I read about suggest that pg_restore is too slow. > > I have noted that the last split file segment will often appear to be > done -- no file modifications -- while pg_dump

Re: [GENERAL] pg_dump slower than pg_restore

2014-07-04 Thread David Wall
signfor 20 0 15032 1372 1004 R 0.7 0.0 0:00.27 top -c 7550 esignfor 20 0 98.6m 592 472 S 0.3 0.0 0:49.80 split -b 51200 - /home/esignforms/customers/archive/db/dump.20140704.gz.gpg -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your sub

Re: [GENERAL] Random-looking primary keys in the range 100000..999999

2014-07-04 Thread Tom Lane
Kynn Jones writes: > The requirements I've been given for the keys is that they be numeric, > reasonably easy to type (hence, no 40-digit keys), never beginning with 0, > and carrying no additional information content (or even suggesting it). Why not just (random()*89)::int + 10 This is

Re: [GENERAL] Random-looking primary keys in the range 100000..999999

2014-07-04 Thread Kynn Jones
On Fri, Jul 4, 2014 at 10:13 AM, hubert depesz lubaczewski wrote: > How many rows do you plan on having in this table? > Currently, only around 10K, but there's expectation that the number will grow. It's hard to predict how much, hence the generous extra space. > Why this particular key rang

Re: [GENERAL] pg_dump slower than pg_restore

2014-07-04 Thread Tom Lane
David Wall writes: > It just seems odd that pg_dump is slower than pg_restore to me. Most > grumblings I read about suggest that pg_restore is too slow. > I have noted that the last split file segment will often appear to be > done -- no file modifications -- while pg_dump is still running, oft

Re: [GENERAL] Random-looking primary keys in the range 100000..999999

2014-07-04 Thread hubert depesz lubaczewski
How many rows do you plan on having in this table? Why this particular key range? depesz On Fri, Jul 4, 2014 at 3:24 PM, Kynn Jones wrote: > I'm looking for a way to implement pseudorandom primary keys in the range > 10..99. > > The randomization scheme does not need to be cryptographi

[GENERAL] Random-looking primary keys in the range 100000..999999

2014-07-04 Thread Kynn Jones
I'm looking for a way to implement pseudorandom primary keys in the range 10..99. The randomization scheme does not need to be cryptographically strong. As long as it is not easy to figure out in a few minutes it's good enough. My starting point for this is the following earlier message

Re: [GENERAL] Windows releases - Bundle OpenSSL includes and .libs in the installer?

2014-07-04 Thread Craig Ringer
On 07/03/2014 05:41 PM, Dave Page wrote: > It shouldn't be an issue for psqlODBC itself as users of that link > against the driver manager not the driver. I suspect what Craig is > trying to do is build the driver against our server installation, which > means he may need OpenSSL now, and other dep

Re: [GENERAL] Migration error " invalid byte sequence for encoding "UTF8": 0xff " from mysql 5.5 to postgresql 9.1

2014-07-04 Thread Albe Laurenz
John R Pierce wrote: > On 7/4/2014 2:12 AM, sunpeng wrote: >> Thank you, friend, I use --hex-blob : >> mysqldump -v -nt --complete-insert=TRUE --compatible=postgresql >> --default-character-set=utf8 --skip-add-locks --compact >> --no-create-info --skip-quote-names --hex-blob -uroot -p test >> vide

Re: [GENERAL] Migration error " invalid byte sequence for encoding "UTF8": 0xff " from mysql 5.5 to postgresql 9.1

2014-07-04 Thread John R Pierce
On 7/4/2014 2:12 AM, sunpeng wrote: Thank you, friend, I use --hex-blob : mysqldump -v -nt --complete-insert=TRUE --compatible=postgresql --default-character-set=utf8 --skip-add-locks --compact --no-create-info --skip-quote-names --hex-blob -uroot -p test videorecresult >dbdata.sql to dump m

Re: [GENERAL] Migration error " invalid byte sequence for encoding "UTF8": 0xff " from mysql 5.5 to postgresql 9.1

2014-07-04 Thread sunpeng
Thank you, friend, I use --hex-blob : mysqldump -v -nt --complete-insert=TRUE --compatible=postgresql --default-character-set=utf8 --skip-add-locks --compact --no-create-info --skip-quote-names --hex-blob -uroot -p test videorecresult >dbdata.sql to dump mysql data. And replace blob data "0x"

Re: [GENERAL] Migration error " invalid byte sequence for encoding "UTF8": 0xff " from mysql 5.5 to postgresql 9.1

2014-07-04 Thread Albe Laurenz
sunpeng wrote: >>> load data to postgresql in cmd(encoding is GBK) is WIN8: >>> >>> psql -h localhost -d test -U postgres < dbdata.sql >>> >>> I got the error: >>> ERROR: invalid byte sequence for encoding "UTF8": 0xff >> If the encoding is GBK then you will get errors (or incorrect >> charact