2009/12/23 Ivan Sergio Borgonovo :
> On Wed, 23 Dec 2009 11:36:31 -0500
> Tom Lane wrote:
>
>> Craig Ringer writes:
>> > Pavel Stehule wrote:
>> >> these queries are executed in some special mode, but still it
>> >> is more expensive than C a = a + 1
>>
>> > ... and may have different rules, so y
On Wed, 23 Dec 2009 11:36:31 -0500
Tom Lane wrote:
> Craig Ringer writes:
> > Pavel Stehule wrote:
> >> these queries are executed in some special mode, but still it
> >> is more expensive than C a = a + 1
>
> > ... and may have different rules, so you can't just write a
> > simple "map express
Craig Ringer writes:
> Pavel Stehule wrote:
>> these queries are executed in some special mode, but still it is more
>> expensive than C a = a + 1
> ... and may have different rules, so you can't just write a simple "map
> expressions to C equivalents" arithmetic evaluator.
Yeah. As an example,
2009/12/23 Ivan Sergio Borgonovo :
> On Wed, 23 Dec 2009 14:35:27 +0100
> Pavel Stehule wrote:
>
>
>> a) simplicity. PLpgSQL interpret is very simple.
>> b) mostly types are little bit different behave than natural C
>> types - domains are different, C types doesn't know NULL value, ...
>
> But we
Pavel Stehule wrote:
> The problem is massive cycle. Plpgsql really isn't language for this.
> This interpret missing own arithmetic unit. So every expression is
> translated to SELECT statement
>
> IF a > c ~ SELECT a > c
> a = a + 1 ~ SELECT a + 1
>
> these queries are executed in some special
On Wed, 23 Dec 2009 14:35:27 +0100
Pavel Stehule wrote:
> a) simplicity. PLpgSQL interpret is very simple.
> b) mostly types are little bit different behave than natural C
> types - domains are different, C types doesn't know NULL value, ...
But well... there should be a mapping somewhere betwe
2009/12/23 Ivan Sergio Borgonovo :
> On Wed, 23 Dec 2009 12:52:38 +0100
> Pavel Stehule wrote:
>
>> The problem is massive cycle. Plpgsql really isn't language for
>> this. This interpret missing own arithmetic unit. So every
>> expression is translated to SELECT statement
>>
>> IF a > c ~ SELECT
On Wed, 23 Dec 2009 12:52:38 +0100
Pavel Stehule wrote:
> The problem is massive cycle. Plpgsql really isn't language for
> this. This interpret missing own arithmetic unit. So every
> expression is translated to SELECT statement
>
> IF a > c ~ SELECT a > c
> a = a + 1 ~ SELECT a + 1
> these qu
2009/12/23 Ivan Sergio Borgonovo :
> On Wed, 23 Dec 2009 08:38:52 +0100
> Pavel Stehule wrote:
>
>> > As even more unexpected... when all row are >0 and most of them
>> > are equal to 1 the generate_series performs appreciably better
>> > (roughly 15% faster).
>> > And I think your version can be
On Wed, 23 Dec 2009 08:38:52 +0100
Pavel Stehule wrote:
> > As even more unexpected... when all row are >0 and most of them
> > are equal to 1 the generate_series performs appreciably better
> > (roughly 15% faster).
> > And I think your version can be further optimised:
> > select count(*) from
2009/12/23 Ivan Sergio Borgonovo :
> On Wed, 23 Dec 2009 01:09:40 +0100
> Ivan Sergio Borgonovo wrote:
>
>> On Wed, 23 Dec 2009 00:00:31 +0100
>> Ivan Sergio Borgonovo wrote:
>>
>> > On Tue, 22 Dec 2009 20:47:18 +0100
>> > Pavel Stehule wrote:
>> >
>> > > Hello
>> > >
>> > > I found one ugly tri
On Wed, 23 Dec 2009 01:09:40 +0100
Ivan Sergio Borgonovo wrote:
> On Wed, 23 Dec 2009 00:00:31 +0100
> Ivan Sergio Borgonovo wrote:
>
> > On Tue, 22 Dec 2009 20:47:18 +0100
> > Pavel Stehule wrote:
> >
> > > Hello
> > >
> > > I found one ugly trick. You can multiply lines and SUM > cons
> >
On Wed, 23 Dec 2009 00:00:31 +0100
Ivan Sergio Borgonovo wrote:
> On Tue, 22 Dec 2009 20:47:18 +0100
> Pavel Stehule wrote:
>
> > Hello
> >
> > I found one ugly trick. You can multiply lines and SUM > cons
> > could be replaced limit clause:
>
> The trick is really smart (and fun), kudos, rea
On Tue, 22 Dec 2009 20:47:18 +0100
Pavel Stehule wrote:
> Hello
>
> I found one ugly trick. You can multiply lines and SUM > cons
> could be replaced limit clause:
The trick is really smart (and fun), kudos, really, it's always a
pleasure to read your solutions, thanks.
But as expected:
In a
Hello
I found one ugly trick. You can multiply lines and SUM > cons could be
replaced limit clause:
postgres=# select * from data;
a
---
3
2
1
4
2
3
(6 rows)
Then SELECT * FROM WHERE and stop when SUM(a) = n
then
postgres=# select generate_series(1,a) from data;
generate_series
---
> Sorry, but i don't know how a CTE can help in this case, can you explain
I mean RECURSIVE CTE. You can check your condition on each iteration and stop
execution when condition is false.
Sergey
> msi77 wrote:
> > Развернуть
> > Does PG support CTE?
> Since 8.4 yes.
> > Развернуть
> > You ca
msi77 wrote:
> Does PG support CTE?
Since 8.4 yes.
> You can try it.
Sorry, but i don't know how a CTE can help in this case, can you explain
that?
Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (L
On Tue, 22 Dec 2009 14:48:55 +0100
Filip Rembiałkowski wrote:
> With plain SQL, no.
>
> With a user defined function in PL/PgSQL, yes.
thanks to all.
I'm on 8.3 so no CTE.
I was hoping there was some way to write it in plain SQL.
I'm planning to wrap everything in a plpgsql function using curs
Does PG support CTE?
You can try it.
> In response to Ivan Sergio Borgonovo :
> > Развернуть
> > Hi,
> >
> > I'd like to know if
> >
> > select sum(qty) from t where status=37;
> >
> > is > constant.
> >
> > qty is always >0.
> >
> > Is there a way to skip examining further rows and return a
In response to Ivan Sergio Borgonovo :
> Hi,
>
> I'd like to know if
>
> select sum(qty) from t where status=37;
>
> is > constant.
>
> qty is always >0.
>
> Is there a way to skip examining further rows and return a result
> ASAP?
I think no.
But you can create a new table with 2 columns: s
On Tue, 2009-12-22 at 13:35 +0100, Ivan Sergio Borgonovo wrote:
> Hi,
> I'd like to know if
> select sum(qty) from t where status=37;
> is > constant.
> qty is always >0.
> Is there a way to skip examining further rows and return a result
> ASAP?
SELECT SUM(object_version)
FROM date_x
WHERE owner_
2009/12/22 Ivan Sergio Borgonovo
> Hi,
>
Hi :-)
>
> I'd like to know if
>
> select sum(qty) from t where status=37;
>
> is > constant.
>
> qty is always >0.
>
> Is there a way to skip examining further rows and return a result
> ASAP?
>
With plain SQL, no.
With a user defined function in PL
Hi,
I'd like to know if
select sum(qty) from t where status=37;
is > constant.
qty is always >0.
Is there a way to skip examining further rows and return a result
ASAP?
--
Ivan Sergio Borgonovo
http://www.webthatworks.it
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To ma
23 matches
Mail list logo
