Christoph Haller wrote:
PostgreSQL 7.3.2
T1: begin; select * from foo for update;
T2: set STATEMENT_TIMEOUT = 1000; -- milliseconds
Seems like setting it to 1 (ms) emulates the NOWAIT condition better.
Can't set it to 0, though.
T2: select * from foo for update;
T2: ERROR: Query was cancelled.
Tom Lane wrote:
create function greatest(anyelement, anyelement) returns anyelement as
'select case when $1>$2 then $1 else $2 end' language sql;
Any chance of this making it into 7.4's contrib? Maybe with enough
documentation to make it a tutorial for PostgreSQL's user functions?
You do have to
Tom Lane wrote:
But COALESCE is a special feature hard-wired into the parser. There's
no free lunch --- you pay for your extensibility somewhere.
That's what I'm suggesting: hard-wiring LEAST and GREATEST into the
parser. 7.5, maybe?
The question is: is it worth hard-wiring vs functions? (time
Greg Stark wrote:
MAX and MIN are single-parameter aggregate functions. LEAST and GREATEST are
two-parameter (though in postgres they could be defined for 3 and more
parameters) scalar functions.
If LEAST and GREATEST can accept any number of parameters, wouldn't it
make sense to code it like the
On Wed, Aug 09, 2000 at 12:04:13PM -0400, Mark Volpe wrote:
> I have a table with a trigger that can potentially modify a row before it gets
> inserted or updated:
[snip]
> I have another table that tracks changes in the first table with rules:
AFAIK, rules get rewritten first, before triggers
On Wed, Aug 09, 2000 at 02:53:45PM +0800, Ang Chin Han wrote:
> The queries making use of these might be rewritten as:
> 1. select min(a) from t_sum; -- same as above,
> -- but we've less rows to scan
> 2. select cnt from t_sum where a = 1
Apologies in advance for the length of this post, but this has
been bugging me for a week or so.
Consider a table with a primary key pk and a list of attributes a, b
and c:
Table t
pk a b c
---
1 1 1 1
2 1 2 3
: etc :
9998 1 1 1
2 1
On Mon, Aug 07, 2000 at 10:58:27AM -0400, Tom Lane wrote:
> (I assume the lack of "survey_id =" here is just a cut-and-paste error?)
Yup. :)
> I think what you're getting bit by is that the optimizer doesn't
> recognize "var = function(param)" as being a potential indexscan clause.
> Does EXPLA
I have a query which runs fast:
SELECT passwd FROM ticket WHERE name = ticket2name('test-006kdt') AND
survey_id = ticket2survey_id('test-006kdt');
But slows down to a crawl when I wrapped it in a function:
CREATE FUNCTION ticket2passwd(text) RETURNS text AS
'SELECT passwd FROM ticket WH
On Wed, Jun 28, 2000 at 03:00:04AM -0400, Tom Lane wrote:
> Hash joins don't have anything to do with hash indexes.
> A hash join is a join that makes use of a temporary hashtable
> built on-the-fly *in memory* for that join.
Oh, I see.
> The planner could choose to use an indexscan on a hash i
On Wed, Jun 28, 2000 at 10:56:17AM -0400, Tom Lane wrote:
> Ang Chin Han <[EMAIL PROTECTED]> writes:
> If it was like that then a hash index wouldn't have been applicable
> anyway; hashes are only good for strict equality checks. If you want
> something that can do ord
I'm using Postgresql 7.02.
==
# explain select city.name, country.name from country, city
where city.country_id = country.country_id;
NOTICE: QUERY PLAN:
Hash Join (cost=8.85..16.76 rows=75 width=18)
-> Seq Scan on city (
12 matches
Mail list logo
