Re: [GENERAL] NOT IN and NOT EXIST

On 07/04/2014 06:12 AM, Sameer Kumar wrote: > NOT EXISTS translates to HASH ANTI JOIN and NOT IN translates to NOT > (HASHED) operation. > > Given that the columns used in NOT IN clause (for outer as well as > inner) are NOT NULL, should not it translate a NOT IN plan similar to > NOT EXISTS plan?

Re: [GENERAL] pg_dump slower than pg_restore

On 7/4/2014 9:18 PM, Tom Lane wrote: There are only 32 table, no functions, but mostly large objects. Not sure how to know about the LOs, but a quick check from the table sizes I estimate at only 2GB, so 16GB could be LOs. There are 7,528,803 entries in pg_catalog.pg_largeobject. Hmm ... how m

Re: [GENERAL] pg_dump slower than pg_restore

On 7/4/2014 11:30 AM, Bosco Rama wrote: Random thought: What OS & kernel are you running? Kernels between 3.2.x and 3.9.x were known to have IO scheduling issues. This was highlighted most by the kernel in Ubuntu 12.04 (precise) as shown here:

Re: [GENERAL] Very high latency, low bandwidth replication

Hi Bob: On Sat, Jul 5, 2014 at 3:34 PM, Bob Jolliffe wrote: > Though currently I am thinking to address the problem of generating deltas > at the application level rather than to use postgresql features which are > largely optimized for a slightly different set of circumstances and > requirements

Re: [GENERAL] Very high latency, low bandwidth replication

Thanks Stuart. I'll do some measurements on plaintext dump to git. On 2 July 2014 09:46, Stuart Bishop wrote: > On 30 June 2014 15:05, Bob Jolliffe wrote: > > > What are people's thoughts about a more optimal solution? I would like > to > > use a more incremental approach to replication. Th

Re: [GENERAL] Very high latency, low bandwidth replication

Thanks Francisco for these inputs. I hadn't considered log shipping as I knew I didn't want to track changes to all tables (and databases). Setting up a local partial mirror is an interesting thought which hadn't crossed my mind .. I'll giver that some consideration. Though currently I am thinki

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

Thanks!I'll investigate (explain) performance for both versions. Atenciosamente,Edson Richter -- Mensagem original --De: David Johnston Data: 04/07/2014 21h20Para: Edson Richter;Cc:pgsql-general@postgresql.org;Assunto:Re: Re : [GENERAL] Query "top 10 and others"> with QRY as (select C1.coun

Re: [GENERAL] Failed to build transaction for opengeo-server

Hi Adrian and all, thanks for the help. I was able to uninstall opengeo-server. Then I started getting a new error to do with missing dependencies for postgis21. I uninstalled postgis21, updated yum, and reinstalled postgis21. Success. Thanks! On Thu, Jul 3, 2014 at 9:15 AM, Adrian Klaver w

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

On Sat, Jul 5, 2014 at 11:06 AM, Madhurima Das wrote: > int main() > { > PGconn *conn; >PGresult *res; > int i=0,nFields=0,row=0,col=0; > > conn = PQconnectdb("dbname=test1 host=localhost user=postgres > password=yyy"); >if(PQstatus(conn) == CONNECTION_BAD) >{ > fprintf(stderr, "Co

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

On Fri, Jul 04, 2014 at 09:24:31AM -0400, 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