On Wed, May 30, 2012 at 9:37 AM, Waldecir Faria 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 or inserting
> a tupl
> 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,
On Mon, May 28, 2012 at 8:15 AM, Waldecir Faria 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 suggested me
> to take a
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 P
> [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
>> myrank(t1.c
>> 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)
[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
> myrank(t1.column1,t
> [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" fu
> 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 m
> [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" fu
[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
[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 do
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'
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
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 calcul
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 (
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
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;
e
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 thing
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
http://www.postgresql.o
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:
> 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.
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 argum
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 pro
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 expressio
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 t
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 m
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 questio
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 v
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
>> 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
> 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 n
> regression=# SELECT update_pg_pwd();
> ERROR: getTypeOutputInfo: Cache lookup of type 0 failed
>
> which is not exactly pretty, but it beats a core dump. "SELECT NULL"
> still works.
Maybe the regression test database should have tests for all the built-in
functions?
Chris
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Feel free to wack it around.
Removing the special-case logic in ExecTypeFromTL yields
regression=# SELECT update_pg_pwd();
ERROR: getTypeOutputInfo: Cache lookup of type 0 failed
which is not exactly pretty, but it beats a core dump. "SELECT NULL"
s
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
> wit
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
Does the same thing here.
Sounds like a serious problem to me too.
Greg
On Wed, 2002-03-20 at 20:46, Bruce Momjian wrote:
> 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? I am sure ther
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? I am sure there are other cases too. Isn't it a
problem that we let ordinary users crash the server and cause a restart?
--
37 matches
Mail list logo
