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

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 !!!

ster 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: +6281648

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, you

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 30ms. > It's a similar probl

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

hash = 0; size_t i = 0; for (i=0;i wrote: > And in any case, there's no crc32 in the built-in pgcrypto module. > > > On 17 June 2016 at 06:18, Claudio Freire wrote: > >> On Fri, Jun 17, 2016 at 1:09 AM, julyanto SUTANDANG >> wrote: >> > This way is doi

Re: [PERFORM] Indexes for hashes

;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 SUTANDANG Equnix Busi

Re: [PERFORM] Indexes for hashes

7aa | >> \x2061bd05049c51bd1162e4d77f72a37f06d2397fc522ef587ed172a5ad8d57aa >> (10 rows) >> >> created two indexes: >> create index i1 on new (texthex); >> create index i2 on new (a_bytea); >> >> i1 is 91MB, and i2 is 56MB. >> >> Index c