Thanks.. I'll keep those issues in mind.
On Sat, Mar 24, 2012 at 6:18 PM, Tatsuo Ishii wrote:
> >> Well, you'd have to start by demonstrating the benefit of it. The
> >> advantage of query caches in proxies and clients is well-known, because
> you
> >> can offload some of the work of the datab
On Sat, Mar 24, 2012 at 3:22 PM, Joshua Berkus wrote:
> Billy,
>
> > I've done a brief search of the postgresql mail archives, and I've
> > noticed a few projects for adding query caches to postgresql, (for
> > example, Masanori Yamazaki's query cache pro
27;ve had many of these thoughts myself, and I guess
it depends on the environment the database will be used, memory settings,
and other variables, on how valuable a query cache would be. I'll
definitely give this more thought before sending an official proposal.
Billy
r the experts out there, does this seem reasonable, or am I
misunderstanding the source code? Anyone aware of a project trying to
accomplish this?
Thanks!
Billy Earney
Tom,
Thanks for your reply. So is the group leaning towards just maintaining
the current regex code base, or looking into introducing a new library
(RE2, PCRE, etc)? Or is this still open for discussion?
Thanks!
Billy
On Mon, Feb 20, 2012 at 3:35 PM, Tom Lane wrote:
> Billy Earney wri
Jay,
Good links, and I've also looked at a few others with benchmarks. I
believe most of the benchmarks are done before PCRE implemented jit. I
haven't found a benchmark with jit enabled, so I'm not sure if it will make
a difference. Also I'm not sure how accurately the benchmarks will show
how
pcre
library? It seems to have a lot of neat features, and also has a jit, and
it looks like it is being actively maintained and has decent comments.
On Sun, Feb 19, 2012 at 7:40 PM, Tom Lane wrote:
> Billy Earney writes:
> > I did a google search, and found the following:
> > ht
e. I didn't
download and analyze their code, but maybe they have made some comments
that could help, or maybe have some improvements to the code..
Just a thought.. :)
Billy Earney
On Sun, Feb 19, 2012 at 5:42 PM, Tom Lane wrote:
> Brendan Jurd writes:
> > Are you far enough into th
open cursorSrc for queryStr;
Here queryStr is a variable which type is TEXT OR VARCHAR or other string types.
But in PLPGSQL, we can only open a cursor this way:
open cursorSrc for select * from testtable;
We cannot substitude "select * from testtable" with a variab
Trigger(s) */
{
is FALSE for ever.
I think we can add some judgment conditions in function
plpgsql_exec_trigger() to avoid this problem.
billy
[EMAIL PROTECTED]
2008-06-11
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
-10 23:43:00 In your letter you say:===
>"billy" <[EMAIL PROTECTED]> writes:
>> I think we can add some judgment conditions in function
>> plpgsql_exec_trigger() to avoid this problem.
>
>I don't especially see the point of adding extra comp
is FALSE for ever.
I think we can add some judgment conditions in function
plpgsql_exec_trigger() to avoid this problem.
billy
[EMAIL PROTECTED]
2008-06-11
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
> > > I think it's great - but don't quote me on that. :)
> > >
> >
> > PostgreSQL. Because life's too short to learn Oracle.
>
> PostgreSQL. For those with more to do than babysit a database.
>
Ah, better. More orthogonal.
---(end of broadcast)-
can quote you!
>
>
> I think it's great - but don't quote me on that. :)
>
PostgreSQL. Because life's too short to learn Oracle.
:)
Billy O'Connor
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
may not be necessary for it to occur on a particular platform. The patch
to Makefile.global.in provides the means by which the individual ports can add
the additional search paths. It's up to the port maintainers to decide if
it's needed for their port, IMHO.
--
| Billy G
e executable(s) will have the runtime search paths in them so they will
execute without having to change the default LD_LIBRARY_PATH setting.
--
| Billy G. Allie| Domain: [EMAIL PROTECTED]
| /| | 7436 Hartwell | MSN...: [EMAIL PROTECTED]
|-/-|- | Dearborn, MI 48126|
|/ |LLIE | (313) 582-1540|
msg24907/pgp0.pgp
Description: PGP signature
was compiling using the native (UDK) compiler. and it failed in tuplesort.c.
It was also unable to file the readline shared libraries without the changes to the
makefiles or setting LD_RUN_PATH (which is a pain and is depreciated in OpenUNIX 8 and
UnixWare 7).
--
| Billy G. Allie
). If I remove the inline from ApplySortFunction, it
compiles and builds. In order for tuplesort.c to compile on OpenUNIX the code
must be changed to either:
1. Remove the static modifier from myFuntionCall2
or
2. Remove the inline from ApplySortFunction
or
3. Wrap the static mo
Tom Lane wrote:
> "Billy G. Allie" <[EMAIL PROTECTED]> writes:
> > Here is the error messages generated during the compile:
>
> > cc -K pentium_pro,host,inline,loop_unroll -I../../../../src/include
> > -I/usr/local/include -I/usr/local/ssl/include -c -o
Tom Lane wrote:
> "Billy G. Allie" <[EMAIL PROTECTED]> writes:
> > Here is the error messages generated during the compile:
>
> > cc -K pentium_pro,host,inline,loop_unroll -I../../../../src/include
> > -I/usr/local/include -I/usr/local/ssl/include -c -o
R_works = @ld_R_works@
+ # Set trpath to a list of library paths included in LDFLAGS
+ # These paths can be added to rpath in the port specific makefiles if needed.
+ trpath = $(filter -L%,@LDFLAGS@)
LDFLAGS = @LDFLAGS@
LDREL = -r
LDOUT = -o
| Billy G. Allie| Domain: [EM
rop create anyway? Is there some
technical difference?
--
Billy O'Connor
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
If it compiles and passes regress tests that way, you're
> better off without the #define anyhow.
--
| Billy G. Allie| Domain: [EMAIL PROTECTED]
| /| | 7436 Hartwell | Compuserve: 76337,2061
|-/-|- | Dearborn, MI 48126| MSN...: [EMAIL PROTECTED]
|/ |LLIE | (313) 582-1540|
PGP signature
Tom Lane wrote:
> "Billy G. Allie" <[EMAIL PROTECTED]> writes:
> > Peter Eisentraut wrote:
> >> Sounds interesting, but isn't "pgsql" an extremely unfortunate choice of
> >> name, given that it's already used as an abbreviation for
Peter Eisentraut wrote:
> Billy G. Allie writes:
>
> > PgSQL v1.0 has been released. This is the first public release of PgSQL.
> > It is available at http://sourceforge.net/projects/pgsql.
>
> Sounds interesting, but isn't "pgsql" an extremely unfort
d them.
You need to make the following changes to access the PostgreSQL man pages
from UnixWare.
| Billy G. Allie| Domain: [EMAIL PROTECTED]
| /| | 7436 Hartwell | Compuserve: 76337,2061
|-/-|- | Dearborn, MI 48126| MSN...: [EMAIL PROTECTED]
|/ |LLIE | (313) 582-1540|
PGP signature
://www.python.org.
--
| Billy G. Allie| Domain: [EMAIL PROTECTED]
| /| | 7436 Hartwell | Compuserve: 76337,2061
|-/-|- | Dearborn, MI 48126| MSN...: [EMAIL PROTECTED]
|/ |LLIE | (313) 582-1540|
PGP signature
27 matches
Mail list logo
