Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id 5BD3C98F703 for ; Tue, 5 Jun 2012 00:49:46 -0300 (ADT) Received: from na3sys009aog134.obsmtp.com ([74.125.149.83]) by makus.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1Sbkm8-0001cT-Rb for pgsql-performance@postgresql.org; Tue, 05 Jun 2012 03:49:45 +0000 Received: from mail-pz0-f52.google.com ([209.85.210.52]) (using TLSv1) by na3sys009aob134.postini.com ([74.125.148.12]) with SMTP ID DSNKT82By/TfyNgajHyJWvjcYXghdo6YvDjD@postini.com; Mon, 04 Jun 2012 20:49:44 PDT Received: by dano14 with SMTP id o14so7526547dan.11 for ; Mon, 04 Jun 2012 20:49:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=6J8/VB5JB7mr6GHrfKgscOKGTakhIrbOgivLp6V2L7A=; b=Mkx5dZOwd+gnw/uYHmNZUMwBb+FfTh0v822FxSSA8cO7A+d479ATZ2d5flTc21aKY+ XWr+bcF39nZSTRXU2pa5ZLY/OFAWEJksNEQThs5vv07Z7L1KAPUtTx9FoxUZBkSYK4ny FJbfKfr80GiNaer+3IRp4rCHOm3XVv6oEDIQgZ1SQAEEq3e8ga3B7aWCnSw4YmLg/maa Ttl0AZD6bH5pNhLoP3xm0uNdTVuQiwwdqb++kbXTEcUO7CLphO5dNZkrp2BLGacxtdkw N91sGdCfgUhl3I4bkzfCcrE+Uh2DqkxEPeqIKoqb+bPp1/ExKLWdF22CdOk5TZ7FbpBL +SIg== Received: by 10.68.204.227 with SMTP id lb3mr46578465pbc.92.1338868171040; Mon, 04 Jun 2012 20:49:31 -0700 (PDT) Received: from [172.20.9.121] (eth59-167-133-99.static.internode.on.net. [59.167.133.99]) by mx.google.com with ESMTPS id sy3sm876377pbc.18.2012.06.04.20.49.27 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Jun 2012 20:49:29 -0700 (PDT) Message-ID: <4FCD81C4.9030807@atlassian.com> Date: Tue, 05 Jun 2012 13:49:24 +1000 From: Trevor Campbell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Maciek Sakrejda CC: Vitalii Tymchyshyn , Craig James , pgsql-performance@postgresql.org Subject: Re: Trouble with plan statistics for behaviour for query. References: <4FC7F0DB.40600@atlassian.com> <4FC7F844.8070205@atlassian.com> <4FC80000.2000900@atlassian.com> <4FC8862B.70103@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnSz6YV+8nF39+8QXUh6lEzosBmy3CaTr65GswV0Xi1NaiOgwais6nAzdfytrR+1N5OkI5l X-Pg-Spam-Score: -4.2 (----) X-Archive-Number: 201206/18 X-Sequence-Number: 47044 > Actually, I'm rather surprised to see 'real' there: if you're using setObject with a Long, I would imagine that turns > into a bigint (which I believe the server knows how to coerce to numeric). The (real) is just my fault in testing. I just copy/pasted from elsewhere and it is not what is coming from the JDBC driver, I don't know how to see what the driver is actually sending.