Re: [PERFORM] Backup taking long time !!!

and Regards, Jul. Julyanto SUTANDANG Equnix Business Solutions, PT (An Open Source and Open Mind Company) www.equnix.co.id Pusat Niaga ITC Roxy Mas Blok C2/42. Jl. KH Hasyim Ashari 125, Jakarta Pusat T: +6221 2282 F: +62216315281 M: +628164858028 Caution: The information enclosed in this email

Re: [PERFORM] Backup taking long time !!!

and across location, not only within an Instance. Thanks, Julyanto SUTANDANG Equnix Business Solutions, PT (An Open Source and Open Mind Company) www.equnix.co.id Pusat Niaga ITC Roxy Mas Blok C2/42. Jl. KH Hasyim Ashari 125, Jakarta Pusat T: +6221 2282 F: +62216315281 M: +628164858028

Re: [PERFORM] Backup taking long time !!!

Hi Stephen, > > When PostgreSQL in the mode of Start Backup, PostgreSQL only writes to > the > > XLOG, then you can safely rsync / copy the base data (snapshot) then > later > > you can have full copy of snapshot backup data. > > You are confusing two things. > > After calling pg_start_backup,

Re: [PERFORM] Backup taking long time !!!

than copy all the data. my latter explanation is: use pg_basebackup, it will do it automatically for you. CMIIW, Julyanto SUTANDANG Equnix Business Solutions, PT (An Open Source and Open Mind Company) www.equnix.co.id Pusat Niaga ITC Roxy Mas Blok C2/42. Jl. KH Hasyim Ashari 125, Jakarta Pusat

Re: [PERFORM] Backup taking long time !!!

CORRECTION: "you might you pg_start_backup to tell the server not to write into the DATADIR" become "you might *use* pg_start_backup to tell the server not to write into the *BASEDIR*, actually server still writes but only to XLOGDIR " Regards, Julyanto SUTAND

Re: [PERFORM] Backup taking long time !!!

longer downtime to recover the backup data. By that way, recovering is only starting up the postgres with that copy. Good luck! Julyanto SUTANDANG Equnix Business Solutions, PT (An Open Source and Open Mind Company) www.equnix.co.id Pusat Niaga ITC Roxy Mas Blok C2/42. Jl. KH Hasyim Ashari 125

Re: [PERFORM] Millions of tables

-sorry for my last email, which also not bottom posting- Hi Greg, On Mon, Sep 26, 2016 at 11:19 AM, Greg Spiegelberg wrote: > I did look at PostgresXL and CitusDB. Both are admirable however neither > could support the need to read a random record consistently under

Re: [PERFORM] Millions of tables

Dear Greg, Have you checked PostgresXL ? with millions of table, how the apps choose which table is approriate? in my opinion, with that scale it should go with parallel query with data sharing like what PostgresXL is done. Thanks, Julyanto SUTANDANG Equnix Business Solutions, PT (An Open

Re: [PERFORM] Postgresql 8.4 optimize for heavy select load

You might wanted to upgrade to new version 9.5 with small effort by using pg_upgrade, we have done upgrading and achieve more than 20x faster from 8.4 to 9.5 (it depends on the type of sql statement actually) Jul. Julyanto SUTANDANG Equnix Business Solutions, PT (An Open Source and Open Mind

Re: [PERFORM] Indexes for hashes

sfre...@gmail.com> wrote: > >> On Fri, Jun 17, 2016 at 1:09 AM, julyanto SUTANDANG >> <julya...@equnix.co.id> wrote: >> > This way is doing faster using crc32(data) than hashtext since crc32 is >> > hardware accelerated in intel (and others perhaps) >&

Re: [PERFORM] Indexes for hashes

shtext(fieldname) = hashtext('blabla') AND > fieldname = 'blabla'; > > > -- > Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance > -- Julyanto SUTAND

Re: [PERFORM] Indexes for hashes

d1162e4d77f72a37f06d2397fc522ef587ed172a5ad8d57aa | >> \x2061bd05049c51bd1162e4d77f72a37f06d2397fc522ef587ed172a5ad8d57aa >> (10 rows) >> >> created two indexes: >> create index i1 on new (texthex); >> create index i2 on new (a_bytea); >> >> i1 is 91MB,