On Jun 21, 2006, at 19:24, Michael Glaesemann wrote:
I haven't seen it mentioned in this thread yet, but have you looked
at citext?
http://gborg.postgresql.org/project/citext/projdisplay.php
I don't have any experience with it, but perhaps it can do what
you're looking for.
Yes, I've see
On Jun 21, 2006, at 18:19, Josh Berkus wrote:
Well, current case-insensitivity hacks definitely aren't compatible
with
LIKE as far as "begins with" indexes are concerned.
Yes, currently I use LOWER() for my indexes and for all LIKE, =, etc.
queries. This works well, but ORDER by of course
On Jun 21, 2006, at 13:08, Tom Lane wrote:
There are some reports in the archives of particular usage patterns
where they pretty much suck, because GetDomainConstraints() searches
pg_constraint every time it's called. We do what we can to avoid
calling that multiple times per query, but for som
Howdy,
Didn't see anything in the archives, so I thought I'd ask: has anyone
done any work to gauge the performance penalty of using DOMAINs? I'm
thinking of something like Elein's email DOMAIN:
http://www.varlena.com/GeneralBits/
I figured that most simple domains that have a constraint
On Jun 12, 2006, at 19:44, Tom Lane wrote:
(Personally, if I'd designed it, the libraries would actually live in
/usr/lib32 and /usr/lib64, and /usr/lib would be a symlink to
whichever
you needed it to be at the moment. Likewise for /usr/bin.)
/me nominates Tom to create a Linux distributi
On May 21, 2006, at 12:23, Josh Berkus wrote:
Well, per our conversation the approach doesn't really work. EXECUTE
'string' + generate_series seems to carry a substantial and
somewhat random
overhead, between 100ms and 200ms -- enough to wipe out any
differences
between queries.
Per our
Fellow PostgreSQLers,
With a bit of guidance from Klint Gore, Neil Conway, Josh Berkus, and
Alexey Dvoychenkov, I have written a PL/pgSQL function to help me
compare the performance between different functions that execute the
same task. I've blogged the about the function here:
http://
On May 16, 2006, at 18:29, Christopher Kings-Lynne wrote:
Yes, but there are definitely programming cases where memoization/
caching definitely helps. And it's easy to tell for a given
function whether or not it really helps by simply trying it with
CACHED and without.
Would this be a simpl
On May 15, 2006, at 21:31, Tom Lane wrote:
Sure. As I read it, that's talking about a static transformation:
planner sees 2 + 2 (or if you prefer, int4pl(2,2)), planner runs the
function and replaces the expression with 4. Nothing there about
memoization.
Oh, I see. So it's more like a const
On May 15, 2006, at 20:21, Tom Lane wrote:
So, what gives? Am I missing something, or not understanding how
IMMUTABLE works?
The latter.
Hee-hee! And after all those nice things I wrote about you in a
previous email on this list!
But seriously, the documentation says (as if I need to tel
Performance Folks,
I just had an article[1] published in which I demonstrated recursive
PL/pgSQL functions with this function:
CREATE OR REPLACE FUNCTION fib (
fib_for int
) RETURNS integer AS $$
BEGIN
IF fib_for < 2 THEN
RETURN fib_for;
END IF;
RETURN fib(fib_for - 2)
On May 2, 2006, at 16:52, David Wheeler wrote:
Actually looks pretty good to me. Although is generate_series()
being rather slow?
Scratch that:
Bah, dammit, there were no rows in that relevant table. Please
disregard my previous EXPLAIN ANALYZE posts.
I've re-run my scrip
On May 2, 2006, at 16:49, David Wheeler wrote:
On Apr 25, 2006, at 19:36, Tom Lane wrote:
Try one of the actual queries from the plpgsql function.
Here we go:
try=# PREPARE foo(int, int[], int) AS
try-# INSERT INTO entry_coll_tag (entry_id, tag_id, ord )
try-# SELECT $1, $2[gs.ser], gs.ser
On Apr 25, 2006, at 19:36, Tom Lane wrote:
Try one of the actual queries from the plpgsql function.
Here we go:
try=# PREPARE foo(int, int[], int) AS
try-# INSERT INTO entry_coll_tag (entry_id, tag_id, ord )
try-# SELECT $1, $2[gs.ser], gs.ser + $3
try-# FROM generate_series(1, array_upper(
On Apr 25, 2006, at 19:36, Tom Lane wrote:
It looks like you had something trivial as the definition of foo().
Yeah, the function call. :-)
Try one of the actual queries from the plpgsql function.
Oh. Duh. Will do. Tomorrow.
Best,
David
---(end of broadcast)
On Apr 25, 2006, at 18:19, Tom Lane wrote:
You'd really have to look at the plans generated for each of the
commands in the functions to be sure. A knee-jerk reaction is to
suggest that that NOT IN might be the core of the problem, but it's
only a guess.
Well, the rows are indexed (I forgot t
Fellow PostgreSQLers,
This post is longish and has a bit of code, but here's my question up-
front: Why are batch queries in my PL/pgSQL functions no faster than
iterating over a loop and executing a series of queries for each
iteration of the loop? Are batch queries or array or series
gen
17 matches
Mail list logo
