Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id 34CFCEEA155 for ; Wed, 14 Dec 2011 03:02:27 -0400 (AST) Received: from nm1.bullet.mail.sp2.yahoo.com ([98.139.91.71]) by makus.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1Rair9-0004JX-Oa for pgsql-performance@postgresql.org; Wed, 14 Dec 2011 07:02:28 +0000 Received: from [98.139.91.64] by nm1.bullet.mail.sp2.yahoo.com with NNFMP; 14 Dec 2011 07:02:11 -0000 Received: from [98.139.91.21] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 14 Dec 2011 07:02:10 -0000 Received: from [127.0.0.1] by omp1021.mail.sp2.yahoo.com with NNFMP; 14 Dec 2011 07:02:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 986044.82466.bm@omp1021.mail.sp2.yahoo.com Received: (qmail 4583 invoked by uid 60001); 14 Dec 2011 07:02:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1323846130; bh=LHnC2VzG4uWxWhwU0lJ/jGBrajxB3GV2rrB7EFyYYtQ=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=CUlLPhWrAOrF1ZkvATwOPbz0oaMPtWmMqRv8dy/XojFqezkWbQOaO3LQo8jKDDkaB+6JStUqLpTh5LTN2oRvfOjNuy6x6cctGxBXNVqzFSnDnrxkPTKkQf65CY2oHnj8clCYpJ75vCAvL+1QzAT8u1Nn+PGjN2RUoZlSHJpTvXI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ZxH4n1CGvvz3midhYkNzViZccKkx2DSdSyHuHgmcPjEw1qhNt87EBKqGBBtBlgKjPWbDzvhJ4Hg1p0p/BekwroVOKV/fN9pi7TTT5TYLsTUyHktApLH5wBshytSJurl3nRhFWCUypnCpxd7BNNEhUpgjVeNAhkOj7OSiIEksaKc=; X-YMail-OSG: 8SPtn0wVM1ls2wyGmGCvF6cyhCUE75Yz5jcj.ZfxgXdP9.z Dp_5p79RMKxBXMnUrrLfcqjhS89BXMnmdLnQjnLlFxBXOGPWpZGOU5eDQwrm s9MI_rltEpzWdJwvuGc6GUNia8HifYyWeneoFPfh8M0G3vlFwFdZdj9A0tZu mDC_88fOrajvrhAZv5aEGRNfugIj9J9zmU5wde17MeeE0eAAV5M0Sc2zoY6H PIILxBSt_S_YHB.7lGT3IaxEe8cDKXTMx4wvPCPFWUJ0vNc8XIYcCOZL.uR8 MTFXXX6KPiSd.JrELDN3PpIdSnZIB7mLnVyvdoD3mgC5pSZMEUuZmFdrJkpP 7rkFVat0QvZkXS8rvhT8MBT3GlX4xiiBKID_YBui4_0oQRtUHgg2h.ea5LnW bLUpKWFAaA0o1eUWVIdd9BqedKfZTMIyiT7blcQ6X6JwHRg18yQexhGzLM3X BomBIRNBb4FqitTSCR7z1tqoo8chB9q8YSJ4wNTskTLOiiWnnpUAYJyrQjuO xL01yV8Sl3s31T5DnC5v7h2uUCZQ- Received: from [86.106.38.101] by web110413.mail.gq1.yahoo.com via HTTP; Tue, 13 Dec 2011 23:02:10 PST X-Mailer: YahooMailWebService/0.8.115.331698 References: <29057.1323843491@sss.pgh.pa.us> Message-ID: <1323846130.44736.YahooMailNeo@web110413.mail.gq1.yahoo.com> Date: Tue, 13 Dec 2011 23:02:10 -0800 (PST) From: idc danny Reply-To: idc danny Subject: Re: copy vs. C function To: "pgsql-performance@postgresql.org" In-Reply-To: <29057.1323843491@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-904208086-536098077-1323846130=:44736" X-Pg-Spam-Score: -4.4 (----) X-Archive-Number: 201112/107 X-Sequence-Number: 45906 ---904208086-536098077-1323846130=:44736 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi guys,=0AA nub question here since I could not figure it out on my own:= =0AI'm using Hamachi to connect different sites into a VPN and their addres= s always starts with 5.*.*.* - the problem I'm facing is that I cannot make= the access restricted to that particular range only.=0ACurrently I got := =0Ahost all all 0.0.0.0/32 md5=0Awhich allows all the IP's, and the try:=0A= host all all 5.0.0.0/32 md5 =0A=0Adoes not work.=0ASo what I am suppose to = add in "pg_hba.conf" in order to achieve my restriction? Please help me,=0A= Thank you,=0ADanny=0A=0A=0A=0A________________________________=0A From: Tom= Lane =0ATo: Jon Nelson =0AC= c: pgsql-performance@postgresql.org =0ASent: Wednesday, December 14, 2011 8= :18 AM=0ASubject: Re: [PERFORM] copy vs. C function =0A =0AJon Nelson writes:=0A> The only thing I have left are these sta= tements:=0A=0A> get_call_result_type=0A> TupleDescGetAttInMetadata=0A> Buil= dTupleFromCStrings=0A> HeapTupleGetDatum=0A> and finally PG_RETURN_DATUM=0A= =0A> It turns out that:=0A> get_call_result_type adds 43 seconds [total: 54= ],=0A> TupleDescGetAttInMetadata adds 19 seconds [total: 73],=0A> BuildTypl= eFromCStrings accounts for 43 seconds [total: 116].=0A=0A> So those three f= unctions account for 90% of the total time spent.=0A> What alternatives exi= st? Do I have to call get_call_result_type /every=0A> time/ through the fun= ction?=0A=0AWell, if you're concerned about performance then I think you're= going=0Aabout this in entirely the wrong way, because as far as I can tell= from=0Athis you're converting all the field values to text and back again.= =0AYou should be trying to keep the values in Datum format and then=0Ainvok= ing heap_form_tuple.=A0 And yeah, you probably could cache the=0Atype infor= mation across calls.=0A=0A=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 regards, tom lane= =0A=0A-- =0ASent via pgsql-performance mailing list (pgsql-performance@post= gresql.org)=0ATo make changes to your subscription:=0Ahttp://www.postgresql= .org/mailpref/pgsql-performance ---904208086-536098077-1323846130=:44736 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi guys,
A nub question here since I could not figure it out o= n my own:
I'm using Hamachi to connect different sit= es into a VPN and their address always starts with 5.*.*.* - t= he problem I'm facing is that I cannot make the access restricted to that p= articular range only.
Currently I got :
=
host all all 0.0.0.0/32 md5
which allows = all the IP's, and the try:
host all all 5.0.0.0/32 m= d5
does not work.
So wha= t I am suppose to add in "pg_hba.conf" in order to achieve my restriction? = Please help me,
Thank you,
Da= nny

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jon Nelson <jnelson+pgsql@jamponi= .net>
Cc: pgsql-per= formance@postgresql.org
Sent: Wednesday, December 14, 2011 8:18 AM
Subject: Re: [PERFORM] copy vs. C function

=0AJon Nelson <jnelson+pgsql@jamponi.net> writes:
>= The only thing I have left are these statements:

> get_call_resu= lt_type
> TupleDescGetAttInMetadata
> BuildTupleFromCStrings> HeapTupleGetDatum
> and finally PG_RETURN_DATUM

> It = turns out that:
> get_call_result_type adds 43 seconds [total: 54],> TupleDescGetAttInMetadata adds 19 seconds [total: 73],
> Build= TypleFromCStrings accounts for 43 seconds [total: 116].

> So thos= e three functions account for 90% of the total time spent.
> What alt= ernatives exist? Do I have to call get_call_result_type /every
> time= / through the function?

Well, if you're concerned about performance = then I think you're going
about this in entirely the wrong way, because = as far as I can tell from
this you're converting all the field values to= text and back again.
You should be trying to keep the values in Datum format and= then
invoking heap_form_tuple.  And yeah, you probably could cache= the
type information across calls.

     &nbs= p;      regards, tom lane

--
Sent via pgsql-= performance mailing list (pgsql-performance@po= stgresql.org)
To make changes to your subscription:
http://www.po= stgresql.org/mailpref/pgsql-performance


---904208086-536098077-1323846130=:44736--