Date: Tue, 29 May 2012 11:33:59 -0400
Subject: Re: [HACKERS] Function call hierarchy/path since getting the buffer
until access its data
From: robertmh...@gmail.com
To: fighter2...@hotmail.com
CC: pgsql-hackers@postgresql.org
On Mon, May 28, 2012 at 8:15 AM, Waldecir Faria fighter2
On Wed, May 30, 2012 at 9:37 AM, Waldecir Faria fighter2...@hotmail.com wrote:
Thank you for the reply Robert. I think I am getting the idea about reading
buffers but I am confused about the writing part, can you give me a function
name where it does some write operations like creating a table
On Mon, May 28, 2012 at 8:15 AM, Waldecir Faria fighter2...@hotmail.com wrote:
Good morning, I am doing a study about buffer management to improve the
performance of one program that does heavy I/O operations. After looking and
reading from different softwares' source codes/texts one friend
Good morning, I am doing a study about buffer management to improve the
performance of one program that does heavy I/O operations. After looking and
reading from different softwares' source codes/texts one friend suggested me to
take a look at the PostgreSQL code. I already took a look at the
Is there a knowable order in which functions are called within a query in
PostgreSQL?
For example I'll use the Oracle contains function, though this is not
exactly what I'm doing, it just illustrates the issue clearly.
select *, score(1) from mytable where contains(mytable.title, 'Winding
Road',
[EMAIL PROTECTED] writes:
For example I'll use the Oracle contains function, though this is not
exactly what I'm doing, it just illustrates the issue clearly.
select *, score(1) from mytable where contains(mytable.title, 'Winding
Road', 1) order by score(1);
The contains function does a
[EMAIL PROTECTED] wrote:
Would it be something like: where clause first, left to right, followed
by select terms, left to right, and lastly the order by clause?
I don't know what ANSI says, nor do I know what PostgreSQL exactly does
at the moment, but, the only thing you can reasonably count on
[EMAIL PROTECTED] writes:
For example I'll use the Oracle contains function, though this is not
exactly what I'm doing, it just illustrates the issue clearly.
select *, score(1) from mytable where contains(mytable.title, 'Winding
Road', 1) order by score(1);
The contains function does a
I was kind of afraid of that. So, how could one implement such a function
set?
Write a function (say, score_contains) that returns NULL whenever
contains would return false, and the score otherwise.
SELECT * FROM (
SELECT *, score_contains(mytable.title, 'Winding Road', 1) AS
score FROM
[EMAIL PROTECTED] writes:
For example I'll use the Oracle contains function, though this is not
exactly what I'm doing, it just illustrates the issue clearly.
select *, score(1) from mytable where contains(mytable.title, 'Winding
Road', 1) order by score(1);
The contains function does a
[EMAIL PROTECTED] writes:
I need to perform an operation during query time and there are multiple
results based on the outcome. For instance: (Lets try this)
select myrank(t1.column1, t2.column2, 1) as rank,
myscore(t1.column1,t2.column2, 1) as score from t1, t2 where
I was kind of afraid of that. So, how could one implement such a
function
set?
Write a function (say, score_contains) that returns NULL whenever
contains would return false, and the score otherwise.
SELECT * FROM (
SELECT *, score_contains(mytable.title, 'Winding Road', 1) AS
score
[EMAIL PROTECTED] writes:
I need to perform an operation during query time and there are multiple
results based on the outcome. For instance: (Lets try this)
select myrank(t1.column1, t2.column2, 1) as rank,
myscore(t1.column1,t2.column2, 1) as score from t1, t2 where
Hi
I've just tried it, and it works. So it's a good work-around.
Though, is it a wanted feature to have a function being performed on
each row before the offset ?
Le mercredi 21 décembre 2005 à 13:41 -0600, Jim C. Nasby a écrit :
Have you tried
SELECT *, test_func(idkeyword)
FROM
On Thu, Dec 22, 2005 at 10:52:58AM +0100, REYNAUD Jean-Samuel wrote:
Hi
I've just tried it, and it works. So it's a good work-around.
Though, is it a wanted feature to have a function being performed on
each row before the offset ?
Well, saying offset 5000 pretty much means to calculate
On Thu, Dec 22, 2005 at 11:18:22AM +0100, Martijn van Oosterhout wrote:
On Thu, Dec 22, 2005 at 10:52:58AM +0100, REYNAUD Jean-Samuel wrote:
Hi
I've just tried it, and it works. So it's a good work-around.
Though, is it a wanted feature to have a function being performed on
each row
Hi all,
We need to find a solution for a strange problem.
We have a plpgsql FUNCTION which performs an heavy job (named
test_func).
CREATE or replace function test_func(z int) returns integer as $$
declare
tst integer;
begin
--
-- Large jobs with z
--
tst := nextval('test_truc');
return tst;
Have you tried
SELECT *, test_func(idkeyword)
FROM (SELECT * FROM tag OFFSET 5000 LIMIT 1)
;
?
This should probably have been on -general, btw.
On Wed, Dec 21, 2005 at 06:44:33PM +0100, REYNAUD Jean-Samuel wrote:
Hi all,
We need to find a solution for a strange problem.
We have a
On Tue, 27 Jan 2004, Tom Lane wrote:
each candidate. func_select_candidate depends on having some notion of
the same argument position, but what does that mean in such a case?
While it is true that I don't know everything about the current code I
still claim that it can not be such a big
Dennis Bjorklund [EMAIL PROTECTED] writes:
Now, the above is just my plan before coding and before understanding
everything. It might work and it might not. So far I've got no reason to
thing that it wont work,
Before you start writing anything, I suggest you read
On Wed, 28 Jan 2004, Tom Lane wrote:
when the programmer simply adds names to the parameter declarations
of a function without changing any call sites. If the presence of
parameter names changes the ambiguity resolution rules at all, I'm
doubtful that we could guarantee not to break things.
I've been looking in the sql200x draft and there are no function calls
with named arguments.
Thinking more about it, I'm not sure if it really is an important addition
at all. I've got a number of requests for the feature. so there are people
that want it, that much I know.
I don't think it's
Dennis Bjorklund wrote:
Thinking more about it, I'm not sure if it really is an important
addition at all. I've got a number of requests for the feature. so
there are people that want it, that much I know.
I like it very much, and I think mostly everyone else does, too. It's
just a question
Peter Eisentraut [EMAIL PROTECTED] writes:
Dennis Bjorklund wrote:
Thinking more about it, I'm not sure if it really is an important
addition at all. I've got a number of requests for the feature. so
there are people that want it, that much I know.
I like it very much, and I think mostly
On Tue, 27 Jan 2004, Tom Lane wrote:
In particular, how will you avoid individually trawling through every
function with a matching name to try to match up the arguments?
I don't think you can avoid that. But it's just done once to find the oid
of the real function, so if it's used multiple
On Tue, 27 Jan 2004, Peter Eisentraut wrote:
just a question of what syntax to use. Personally, I would be OK with
=.
That's also what I'm leaning towards now. As Greg suggested, just making
= a special case as a function parameter. And if one want's to call a
function with an expression
Dennis Bjorklund [EMAIL PROTECTED] writes:
On Tue, 27 Jan 2004, Tom Lane wrote:
func_select_candidate() that involve comparing matches at the same
argument position will break down completely.
I was planning to reorder the arguments before the matching according to
the function prototype so
On Tue, 27 Jan 2004, Tom Lane wrote:
speed hits in parsing them, especially not if the hit occurs whether
one uses the named-parameters feature or not ...
I'll read the rest of the mail more careful tomorrow moring, I just want
to point out directly that for calls that doesn't use named
Dennis Bjorklund [EMAIL PROTECTED] writes:
I'll read the rest of the mail more careful tomorrow moring, I just want
to point out directly that for calls that doesn't use named arguments you
get the exact same speed as before. Except for an extra if() to check if
there are named arguments. I
Removing the special-case logic in ExecTypeFromTL yields
regression=# SELECT update_pg_pwd();
ERROR: getTypeOutputInfo: Cache lookup of type 0 failed
Wouldn't it be nice to make this a feature that allows
stored procedures (void update_pg_pwd ()) ? Correctly register
this function to not
Bruce Momjian [EMAIL PROTECTED] writes:
If I do this as any user:
SELECT update_pg_pwd();
it crashes all backends and causes a server-wide restart. Is this
acceptable behavior?
There are a number of things we might blame this on, all having to do
with the overuse of type OID zero to
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
If I do this as any user:
SELECT update_pg_pwd();
it crashes all backends and causes a server-wide restart. Is this
acceptable behavior?
There are a number of things we might blame this on, all having to do
with the overuse
32 matches
Mail list logo
