From: | Greg Smith <greg(at)2ndquadrant(dot)com> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, oleg(at)sai(dot)msu(dot)su, teodor(at)sigaev(dot)ru |
Subject: | Re: tsearch parser inefficiency if text includes urls or emails - new version |
Date: | 2009-12-08 19:40:06 |
Message-ID: | 4B1EAB96.5050903@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Kevin Grittner wrote:
> Anyway, I'm not sure whether your reply directly answers the point
> I was raising -- peg doesn't do anything with the compiler
> optimization flags under the covers, does it?
>
Not really. It does this:
PGDEBUG="--enable-cassert --enable-debug"
./configure --prefix=$PGINST/$PGPROJECT --enable-depend
--enable-thread-safety $PGDEBUG
Which are pretty standard options. The idea is that you'd use the
default normally, then just set PGDEBUG=" " for a non-debug build--or to
otherwise change the configure flags but still get things done
automatically for you. If it's set before the script starts, it doesn't
change it.
I did try to design things so that you could do any step in the
automated series manually and not have that screw things up. There's
hundreds of lines of code in there just for things like figuring out
whether configure has been run or not yet when it decides you need to
build, so it can try to do the right thing in either case. My hope was
that anyone who tried peg out would find it a net positive time savings
after a single use, glad to hear I accomplished that in your case.
--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2009-12-08 19:41:52 | Re: More broken links in documentation |
Previous Message | Magnus Hagander | 2009-12-08 19:37:18 | Re: More broken links in documentation |