On Wed, Nov 24, 2010 at 10:33 AM, Tom Lane wrote:
> Robert Haas 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:
Hello
2010/11/24 Tom Lane :
> Robert Haas 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!
>
Robert Haas 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 sense. However,
On Wed, Nov 24, 2010 at 1:06 AM, Tom Lane wrote:
> =?ISO-8859-1?Q?C=E9dric_Villemain?=
> 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 b
sorry, there was a broken message
2010/11/24 Pavel Stehule :
> 2010/11/24 Robert Haas :
>> On Tue, Nov 23, 2010 at 8:56 PM, Cédric Villemain
>> wrote:
>>> 2010/11/23 Robert Haas :
On Mon, Nov 22, 2010 at 11:55 PM, Pavel Stehule
wrote:
> ok, I can only recapitulate so this feature
2010/11/24 Robert Haas :
> On Tue, Nov 23, 2010 at 8:56 PM, Cédric Villemain
> wrote:
>> 2010/11/23 Robert Haas :
>>> On Mon, Nov 22, 2010 at 11:55 PM, Pavel Stehule
>>> wrote:
ok, I can only recapitulate so this feature was proposed cca two
months ago, and minimally Tom and maybe you
=?ISO-8859-1?Q?C=E9dric_Villemain?= 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]. AFAIS Pavel didn't want to imp
On Tue, Nov 23, 2010 at 8:56 PM, Cédric Villemain
wrote:
> 2010/11/23 Robert Haas :
>> On Mon, Nov 22, 2010 at 11:55 PM, 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 o
2010/11/23 Robert Haas :
> On Mon, Nov 22, 2010 at 11:55 PM, 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
>> agre
On Mon, Nov 22, 2010 at 11:55 PM, 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 spent my
2010/11/23 David Fetter :
> 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
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/22 Robert Haas :
> On Mon, Nov 22, 2010 at 3:36 PM, Pavel Stehule
> 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
>
On Mon, Nov 22, 2010 at 3:36 PM, Pavel Stehule 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 time doing and how would
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 field
On Mon, Nov 22, 2010 at 8:39 AM, Jaime Casanova wrote:
> On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova wrote:
>> On Thu, Sep 30, 2010 at 7:46 AM, Pavel Stehule
>> wrote:
>>> Hello
>>>
>>> this patch implement a new iteration construct - iteration over an
>>> array. The sense of this new itera
On Mon, Nov 22, 2010 at 6:21 AM, Valentine Gogichashvili
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 PL/pgsql tr
On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova wrote:
> On Thu, Sep 30, 2010 at 7:46 AM, Pavel Stehule
> 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
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, '
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 array_low
2010/11/18 Tom Lane :
> Pavel Stehule writes:
>> 2010/11/18 Alvaro Herrera :
>>> 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 documentation
>
2010/11/18 Tom Lane :
> Pavel Stehule 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 mo
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
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 :
> > >> 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 writes:
> 2010/11/18 Alvaro Herrera :
>> 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 documentation
UNNEST is documented too. Ad
2010/11/18 Alvaro Herrera :
> Excerpts from Pavel Stehule's message of jue nov 18 17:00:04 -0300 2010:
>> 2010/11/18 Andrew Dunstan :
>
>> >> 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
Excerpts from Pavel Stehule's message of jue nov 18 17:00:04 -0300 2010:
> 2010/11/18 Andrew Dunstan :
> >> 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, it's gett
2010/11/18 Andrew Dunstan :
>
>
> On 11/18/2010 02:39 PM, Pavel Stehule wrote:
>>
>> 2010/11/18 Andrew Dunstan:
>>>
>>> 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
2010/11/18 Tom Lane :
> Pavel Stehule 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 belie
On 11/18/2010 02:39 PM, Pavel Stehule wrote:
2010/11/18 Andrew Dunstan:
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, a
2010/11/18 Andrew Dunstan :
>
>
> 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
2010/11/18 Tom Lane :
> Pavel Stehule 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.
2010/11/18 Tom Lane :
> Pavel Stehule writes:
>> 2010/11/18 Tom Lane :
>>> 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 consequences
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.
c
Pavel Stehule 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
> optimizations on PL
Pavel Stehule 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 example:
> for i in 1.
2010/11/18 Tom Lane :
> Pavel Stehule 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 mo
Pavel Stehule writes:
> 2010/11/18 Tom Lane :
>> 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 consequences
>> that we might misinterpr
Pavel Stehule 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 @a.
Really? Bec
2010/11/18 Robert Haas :
> On Thu, Nov 18, 2010 at 1:03 PM, Pavel Stehule
> wrote:
>> 2010/11/18 Robert Haas :
>>> On Thu, Nov 18, 2010 at 12:36 PM, Tom Lane wrote:
I would *much* rather we get the performance benefit by internal
optimization, and forego inventing syntax.
>>>
>>> +1.
>
On Thu, Nov 18, 2010 at 1:03 PM, Pavel Stehule wrote:
> 2010/11/18 Robert Haas :
>> On Thu, Nov 18, 2010 at 12:36 PM, Tom Lane wrote:
>>> I would *much* rather we get the performance benefit by internal
>>> optimization, and forego inventing syntax.
>>
>> +1.
>
> any optimization will be about 10
2010/11/18 Robert Haas :
> On Thu, Nov 18, 2010 at 12:36 PM, Tom Lane 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. See
my tests: on large arrays isn
2010/11/18 Tom Lane :
> Andrew Dunstan 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-synta
On Thu, Nov 18, 2010 at 12:36 PM, Tom Lane 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 pgsql-hackers mailing li
2010/11/18 Tom Lane :
> Pavel Stehule writes:
>> 2010/11/18 Tom Lane :
>>> 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 big
Andrew Dunstan 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 quite difficult
to
Pavel Stehule writes:
> 2010/11/18 Tom Lane :
>> 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 big space
> for optimizing - and i
2010/11/18 Tom Lane :
> Merlin Moncure writes:
>> On Thu, Nov 18, 2010 at 12:47 AM, Tom Lane 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 th
Merlin Moncure writes:
> On Thu, Nov 18, 2010 at 12:47 AM, Tom Lane 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 point, if there is indeed an int
2010/11/18 Pavel Stehule :
> 2010/11/18 Cédric Villemain :
>> 2010/11/18 Robert Haas :
>>> On Thu, Nov 18, 2010 at 10:24 AM, Merlin Moncure wrote:
On Thu, Nov 18, 2010 at 12:47 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova
>> w
On 11/18/2010 10:33 AM, Robert Haas wrote:
On Thu, Nov 18, 2010 at 10:24 AM, Merlin Moncure 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 there any way to miti
2010/11/18 Cédric Villemain :
> 2010/11/18 Robert Haas :
>> On Thu, Nov 18, 2010 at 10:24 AM, Merlin Moncure wrote:
>>> On Thu, Nov 18, 2010 at 12:47 AM, Tom Lane wrote:
Merlin Moncure writes:
> On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova
> wrote:
>> i will start the revie
2010/11/18 Robert Haas :
> On Thu, Nov 18, 2010 at 10:24 AM, Merlin Moncure wrote:
>> On Thu, Nov 18, 2010 at 12:47 AM, Tom Lane wrote:
>>> Merlin Moncure writes:
On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova
wrote:
> i will start the review of this one... but before that sorry
2010/11/18 Robert Haas :
> On Thu, Nov 18, 2010 at 10:24 AM, Merlin Moncure wrote:
>> On Thu, Nov 18, 2010 at 12:47 AM, Tom Lane wrote:
>>> Merlin Moncure writes:
On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova
wrote:
> i will start the review of this one... but before that sorry
On Thu, Nov 18, 2010 at 10:24 AM, Merlin Moncure wrote:
> On Thu, Nov 18, 2010 at 12:47 AM, Tom Lane wrote:
>> Merlin Moncure writes:
>>> On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova
>>> wrote:
i will start the review of this one... but before that sorry for
suggesting this a bit
2010/11/18 Pavel Stehule :
> 2010/11/18 Cédric Villemain :
>> 2010/11/18 Pavel Stehule :
>>> 2010/11/18 Tom Lane :
Merlin Moncure writes:
> On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova
> wrote:
>> i will start the review of this one... but before that sorry for
>> suggest
On Thu, Nov 18, 2010 at 12:47 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova
>> 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?
>
>> Doe
2010/11/18 Cédric Villemain :
> 2010/11/18 Pavel Stehule :
>> 2010/11/18 Tom Lane :
>>> Merlin Moncure writes:
On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova
wrote:
> i will start the review of this one... but before that sorry for
> suggesting this a bit later but about using
2010/11/18 Pavel Stehule :
> 2010/11/18 Tom Lane :
>> Merlin Moncure writes:
>>> On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova
>>> 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?
>>
2010/11/18 Tom Lane :
> Merlin Moncure writes:
>> On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova
>> 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
Merlin Moncure writes:
> On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova 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 does?
Yes, which begs the questi
On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova wrote:
> On Thu, Sep 30, 2010 at 7:46 AM, Pavel Stehule
> 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
On Thu, Sep 30, 2010 at 7:46 AM, Pavel Stehule 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
suggesting this a bit
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 $$
sele
64 matches
Mail list logo
