On Wed, Nov 24, 2010 at 1:06 AM, Tom Lane t...@sss.pgh.pa.us wrote:
=?ISO-8859-1?Q?C=E9dric_Villemain?= cedric.villemain.deb...@gmail.com
writes:
I think you (Robert) misunderstood dramatically what Pavel try to do.
Pavel did an excellent optimization work for a specific point. This
specific
Robert Haas robertmh...@gmail.com writes:
Right, that was my impression, too. But, I think this may be partly a
case of people talking past each other. My impression of this
conversation was a repetition of this sequence:
A: This syntax is bad.
B: But it's way faster!
...which makes no
Hello
2010/11/24 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
Right, that was my impression, too. But, I think this may be partly a
case of people talking past each other. My impression of this
conversation was a repetition of this sequence:
A: This syntax is
On Wed, Nov 24, 2010 at 10:33 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Right, that was my impression, too. But, I think this may be partly a
case of people talking past each other. My impression of this
conversation was a repetition of this sequence:
On Mon, Nov 22, 2010 at 11:55 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
ok, I can only recapitulate so this feature was proposed cca two
months ago, and minimally Tom and maybe you did agreement - with
request on syntax - do you remember? I am little bit tired so this
agreement was
2010/11/23 Robert Haas robertmh...@gmail.com:
On Mon, Nov 22, 2010 at 11:55 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
ok, I can only recapitulate so this feature was proposed cca two
months ago, and minimally Tom and maybe you did agreement - with
request on syntax - do you remember?
On Tue, Nov 23, 2010 at 8:56 PM, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
2010/11/23 Robert Haas robertmh...@gmail.com:
On Mon, Nov 22, 2010 at 11:55 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
ok, I can only recapitulate so this feature was proposed cca two
months ago,
=?ISO-8859-1?Q?C=E9dric_Villemain?= cedric.villemain.deb...@gmail.com writes:
I think you (Robert) misunderstood dramatically what Pavel try to do.
Pavel did an excellent optimization work for a specific point. This
specific point looks crucial for me in the current behavior of
PostgreSQL[1].
2010/11/24 Robert Haas robertmh...@gmail.com:
On Tue, Nov 23, 2010 at 8:56 PM, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
2010/11/23 Robert Haas robertmh...@gmail.com:
On Mon, Nov 22, 2010 at 11:55 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
ok, I can only recapitulate
sorry, there was a broken message
2010/11/24 Pavel Stehule pavel.steh...@gmail.com:
2010/11/24 Robert Haas robertmh...@gmail.com:
On Tue, Nov 23, 2010 at 8:56 PM, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
2010/11/23 Robert Haas robertmh...@gmail.com:
On Mon, Nov 22, 2010 at
Hi,
with the FOR e IN SELECT UNNEST(a) construct there is an issue again related
to the unresting of composite type arrays:
BEGIN;
CREATE TYPE truple AS (i integer, a text, b text);
DO $SQL$
DECLARE
start_time timestamp;
t truple;
ta truple[] := ARRAY( select ROW(s.i, 'A' || (s.i)::text,
On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova ja...@2ndquadrant.com wrote:
On Thu, Sep 30, 2010 at 7:46 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hello
this patch implement a new iteration construct - iteration over an
array. The sense of this new iteration is:
* a simple and
On Mon, Nov 22, 2010 at 6:21 AM, Valentine Gogichashvili
val...@gmail.com wrote:
Hi,
with the FOR e IN SELECT UNNEST(a) construct there is an issue again related
to the unresting of composite type arrays:
[ example ]
Is it a bug or a feature?
It looks like the problem in this example is that
On Mon, Nov 22, 2010 at 8:39 AM, Jaime Casanova ja...@2ndquadrant.com wrote:
On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova ja...@2ndquadrant.com wrote:
On Thu, Sep 30, 2010 at 7:46 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hello
this patch implement a new iteration construct -
Hello
I spent last two days a searching how to solve this problem better.
Probably I removed a issue with toasting. But I found other issue,
that wasn't discussed before. This issue is only seq access to items
via array_seek function. I though about some variable that stores a
last accessed
On Mon, Nov 22, 2010 at 3:36 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
So, please, I know, so you and Tom are busy, but try to spend a few
time about this problem before you are definitely reject this idea.
If I were to spend more time on this problem, what exactly would I
spend that
2010/11/22 Robert Haas robertmh...@gmail.com:
On Mon, Nov 22, 2010 at 3:36 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
So, please, I know, so you and Tom are busy, but try to spend a few
time about this problem before you are definitely reject this idea.
If I were to spend more time on
On Tue, Nov 23, 2010 at 05:55:28AM +0100, Pavel Stehule wrote:
ok, I can only recapitulate so this feature was proposed cca two
months ago, and minimally Tom and maybe you did agreement - with
request on syntax - do you remember? I am little bit tired so this
agreement was changed when I
2010/11/23 David Fetter da...@fetter.org:
On Tue, Nov 23, 2010 at 05:55:28AM +0100, Pavel Stehule wrote:
ok, I can only recapitulate so this feature was proposed cca two
months ago, and minimally Tom and maybe you did agreement - with
request on syntax - do you remember? I am little bit tired
I checked my tests and the most important is a remove a repeated detoast.
postgres=# CREATE OR REPLACE FUNCTION public.filter01(text[], text, integer)
RETURNS text[]
LANGUAGE plpgsql
AS $function$
DECLARE
s text[] := '{}';
l int := 0; i int;
v text; loc text[] = $1;
BEGIN
FOR i IN
2010/11/18 Pavel Stehule pavel.steh...@gmail.com:
2010/11/18 Tom Lane t...@sss.pgh.pa.us:
Merlin Moncure mmonc...@gmail.com writes:
On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova ja...@2ndquadrant.com
wrote:
i will start the review of this one... but before that sorry for
suggesting this a
2010/11/18 Cédric Villemain cedric.villemain.deb...@gmail.com:
2010/11/18 Pavel Stehule pavel.steh...@gmail.com:
2010/11/18 Tom Lane t...@sss.pgh.pa.us:
Merlin Moncure mmonc...@gmail.com writes:
On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova ja...@2ndquadrant.com
wrote:
i will start the
On Thu, Nov 18, 2010 at 12:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova ja...@2ndquadrant.com
wrote:
i will start the review of this one... but before that sorry for
suggesting this a bit later but about
2010/11/18 Pavel Stehule pavel.steh...@gmail.com:
2010/11/18 Cédric Villemain cedric.villemain.deb...@gmail.com:
2010/11/18 Pavel Stehule pavel.steh...@gmail.com:
2010/11/18 Tom Lane t...@sss.pgh.pa.us:
Merlin Moncure mmonc...@gmail.com writes:
On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova
On Thu, Nov 18, 2010 at 10:24 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Thu, Nov 18, 2010 at 12:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova ja...@2ndquadrant.com
wrote:
i will start the review of
2010/11/18 Robert Haas robertmh...@gmail.com:
On Thu, Nov 18, 2010 at 10:24 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Thu, Nov 18, 2010 at 12:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova
2010/11/18 Robert Haas robertmh...@gmail.com:
On Thu, Nov 18, 2010 at 10:24 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Thu, Nov 18, 2010 at 12:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova
2010/11/18 Cédric Villemain cedric.villemain.deb...@gmail.com:
2010/11/18 Robert Haas robertmh...@gmail.com:
On Thu, Nov 18, 2010 at 10:24 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Thu, Nov 18, 2010 at 12:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
On 11/18/2010 10:33 AM, Robert Haas wrote:
On Thu, Nov 18, 2010 at 10:24 AM, Merlin Moncuremmonc...@gmail.com wrote:
Pavel's performance argument is imnsho valid. arrays at present are
the best way to pass data around functions and any optimizations here
are very welcome. Given that, is
2010/11/18 Pavel Stehule pavel.steh...@gmail.com:
2010/11/18 Cédric Villemain cedric.villemain.deb...@gmail.com:
2010/11/18 Robert Haas robertmh...@gmail.com:
On Thu, Nov 18, 2010 at 10:24 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Thu, Nov 18, 2010 at 12:47 AM, Tom Lane
Merlin Moncure mmonc...@gmail.com writes:
On Thu, Nov 18, 2010 at 12:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Yes, which begs the question of why bother at all.
Pavel's performance argument is imnsho valid.
Well, that argument is unsupported by any evidence, so far as I've seen.
More to the
2010/11/18 Tom Lane t...@sss.pgh.pa.us:
Merlin Moncure mmonc...@gmail.com writes:
On Thu, Nov 18, 2010 at 12:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Yes, which begs the question of why bother at all.
Pavel's performance argument is imnsho valid.
Well, that argument is unsupported by any
Pavel Stehule pavel.steh...@gmail.com writes:
2010/11/18 Tom Lane t...@sss.pgh.pa.us:
More to the point, if there is indeed an interesting performance win
here, we could get the same win by internally optimizing the existing
syntax.
sorry, but I don't agree. I don't think, so there are some
Andrew Dunstan and...@dunslane.net writes:
Syntactic sugar is not entirely to be despised, anyway.
If it were harmless syntactic sugar I wouldn't be objecting so loudly.
The problem here is that FOR is a syntactic choke point: it's already
overloaded with several different sub-syntaxes that are
2010/11/18 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2010/11/18 Tom Lane t...@sss.pgh.pa.us:
More to the point, if there is indeed an interesting performance win
here, we could get the same win by internally optimizing the existing
syntax.
sorry, but I don't
On Thu, Nov 18, 2010 at 12:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I would *much* rather we get the performance benefit by internal
optimization, and forego inventing syntax.
+1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via
2010/11/18 Tom Lane t...@sss.pgh.pa.us:
Andrew Dunstan and...@dunslane.net writes:
Syntactic sugar is not entirely to be despised, anyway.
If it were harmless syntactic sugar I wouldn't be objecting so loudly.
The problem here is that FOR is a syntactic choke point: it's already
overloaded
2010/11/18 Robert Haas robertmh...@gmail.com:
On Thu, Nov 18, 2010 at 12:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I would *much* rather we get the performance benefit by internal
optimization, and forego inventing syntax.
+1.
any optimization will be about 10-20% slower than direct access.
On Thu, Nov 18, 2010 at 1:03 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
2010/11/18 Robert Haas robertmh...@gmail.com:
On Thu, Nov 18, 2010 at 12:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I would *much* rather we get the performance benefit by internal
optimization, and forego inventing
2010/11/18 Robert Haas robertmh...@gmail.com:
On Thu, Nov 18, 2010 at 1:03 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2010/11/18 Robert Haas robertmh...@gmail.com:
On Thu, Nov 18, 2010 at 12:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I would *much* rather we get the performance benefit
Pavel Stehule pavel.steh...@gmail.com writes:
what is a slow:
a) repeated detoasting - access with subscripts - maybe detoasted
values can be cached?
b) evaluation of SRF expression - maybe call of SRF function can be
simple expression,
c) faster evaluation ro query
The most important is
Pavel Stehule pavel.steh...@gmail.com writes:
2010/11/18 Tom Lane t...@sss.pgh.pa.us:
The problem here is that FOR is a syntactic choke point: it's already
overloaded with several different sub-syntaxes that are quite difficult
to separate. Â Adding another one makes that worse, with the
2010/11/18 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
what is a slow:
a) repeated detoasting - access with subscripts - maybe detoasted
values can be cached?
b) evaluation of SRF expression - maybe call of SRF function can be
simple expression,
c) faster
Pavel Stehule pavel.steh...@gmail.com writes:
this note was a different -only a few people use FOR IN SELECT UNNEST
for iteration over array. So from Robert's question (what is important
for current code?) perspective the more significant is access to
individual fields via subscripts. For
Pavel Stehule pavel.steh...@gmail.com writes:
unnest returns all fields, but
these fields should not be used. There isn't possible to say - stop, I
don't need other fields. It's possible just with special PL statement,
because it is controlled by PL. So it is reason why I don't believe in
On 11/18/2010 02:17 PM, Pavel Stehule wrote:
-only a few people use FOR IN SELECT UNNEST for iteration over array.
How on earth do you know that? I use it a lot and I was just
demonstrating it to a client yesterday, and I'm quite sure he will use
it a lot too. I bet I'm far from alone.
2010/11/18 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2010/11/18 Tom Lane t...@sss.pgh.pa.us:
The problem here is that FOR is a syntactic choke point: it's already
overloaded with several different sub-syntaxes that are quite difficult
to separate. Adding
2010/11/18 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
this note was a different -only a few people use FOR IN SELECT UNNEST
for iteration over array. So from Robert's question (what is important
for current code?) perspective the more significant is access to
2010/11/18 Andrew Dunstan and...@dunslane.net:
On 11/18/2010 02:17 PM, Pavel Stehule wrote:
-only a few people use FOR IN SELECT UNNEST for iteration over array.
How on earth do you know that? I use it a lot and I was just demonstrating
it to a client yesterday, and I'm quite sure he will
On 11/18/2010 02:39 PM, Pavel Stehule wrote:
2010/11/18 Andrew Dunstanand...@dunslane.net:
On 11/18/2010 02:17 PM, Pavel Stehule wrote:
-only a few people use FOR IN SELECT UNNEST for iteration over array.
How on earth do you know that? I use it a lot and I was just demonstrating
it to a
2010/11/18 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
unnest returns all fields, but
these fields should not be used. There isn't possible to say - stop, I
don't need other fields. It's possible just with special PL statement,
because it is controlled by PL. So
2010/11/18 Andrew Dunstan and...@dunslane.net:
On 11/18/2010 02:39 PM, Pavel Stehule wrote:
2010/11/18 Andrew Dunstanand...@dunslane.net:
On 11/18/2010 02:17 PM, Pavel Stehule wrote:
-only a few people use FOR IN SELECT UNNEST for iteration over array.
How on earth do you know that? I
Excerpts from Pavel Stehule's message of jue nov 18 17:00:04 -0300 2010:
2010/11/18 Andrew Dunstan and...@dunslane.net:
I didn't say so nobody use it. You, me, David. But I really didn't see
this pattern here in real applications.
Lots of people are told to use it on IRC. Trust me,
2010/11/18 Alvaro Herrera alvhe...@commandprompt.com:
Excerpts from Pavel Stehule's message of jue nov 18 17:00:04 -0300 2010:
2010/11/18 Andrew Dunstan and...@dunslane.net:
I didn't say so nobody use it. You, me, David. But I really didn't see
this pattern here in real applications.
Pavel Stehule pavel.steh...@gmail.com writes:
2010/11/18 Alvaro Herrera alvhe...@commandprompt.com:
I fail to see how this supports the FOR-IN-array development though. Â It
will just be another unused construct for most people, no?
maybe I don't understand well, but patch FOR-IN-ARRAY has a
On Thursday 18 November 2010 21:11:32 Alvaro Herrera wrote:
Excerpts from Pavel Stehule's message of jue nov 18 17:00:04 -0300 2010:
2010/11/18 Andrew Dunstan and...@dunslane.net:
I didn't say so nobody use it. You, me, David. But I really didn't see
this pattern here in real
On 11/18/2010 06:06 PM, Andres Freund wrote:
Well, a good reason for that might be that unnest() is pretty new... Most code
I read has been initially written quite a bit earlier. Seeing 8.4 in
production is only starting to get common.
I guess we must have more adventurous customers than you
2010/11/18 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
what is a slow:
a) repeated detoasting - access with subscripts - maybe detoasted
values can be cached?
b) evaluation of SRF expression - maybe call of SRF function can be
simple expression,
c) faster
2010/11/18 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2010/11/18 Alvaro Herrera alvhe...@commandprompt.com:
I fail to see how this supports the FOR-IN-array development though. It
will just be another unused construct for most people, no?
maybe I don't
On Thu, Sep 30, 2010 at 7:46 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
Hello
this patch implement a new iteration construct - iteration over an
array. The sense of this new iteration is:
* a simple and cleaner syntax
i will start the review of this one... but before that sorry for
On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova ja...@2ndquadrant.com wrote:
On Thu, Sep 30, 2010 at 7:46 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hello
this patch implement a new iteration construct - iteration over an
array. The sense of this new iteration is:
* a simple and
Merlin Moncure mmonc...@gmail.com writes:
On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova ja...@2ndquadrant.com wrote:
i will start the review of this one... but before that sorry for
suggesting this a bit later but about using UNNEST as part of the
sintax?
Does for-in-array do what unnset
2010/11/18 Tom Lane t...@sss.pgh.pa.us:
Merlin Moncure mmonc...@gmail.com writes:
On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova ja...@2ndquadrant.com
wrote:
i will start the review of this one... but before that sorry for
suggesting this a bit later but about using UNNEST as part of the
Hello
this patch implement a new iteration construct - iteration over an
array. The sense of this new iteration is:
* a simple and cleaner syntax
* a faster execution - this bring down a number of detoast operations
create or replace function subscripts(anyarray, int)
returns int[] as $$
64 matches
Mail list logo
