From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Vitaly Burovoy <vitaly(dot)burovoy(at)gmail(dot)com> |
Cc: | Harald Fuchs <hari(dot)fuchs(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: execute same query only one time? |
Date: | 2016-02-09 14:43:37 |
Message-ID: | CAKFQuwbvf2ZE6-boTP0uDShErZvTrnkAifYD3sG82WcQxH+pCA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tuesday, February 9, 2016, Vitaly Burovoy <vitaly(dot)burovoy(at)gmail(dot)com>
wrote:
> On 2/9/16, Harald Fuchs <hari(dot)fuchs(at)gmail(dot)com <javascript:;>> wrote:
> > Johannes <jotpe(at)posteo(dot)de <javascript:;>> writes:
> >
> >>> What the reason to execute all statements which return different
> >>> columns at once?
> >>>
> >>>> Saving roundtrips,
> >>>
> >>> In most cases they are not so big. Getting a bunch of duplicated data
> >>> is wasting you network bandwidth and don't increase speed.
> >>
> >> In my and your example no duplicated data (result sets) is send over the
> >> network. The server do not need to wait until the client snips out the
> >> id and sends it id in the next query again. So the server can compute
> >> the result set without external dependencies as fast as possible.
> >
> > Sounds like what you're really after is a stored procedure, isn't it?
>
> Unfortunately, his case is different, because he needs to get two
> different set of rows that is impossible even with stored procedures.
>
>
Correct, though it might be workable to use cursors in this situation. Not
exactly sure how, though...
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-02-09 14:53:02 | Re: COALESCE requires NULL from scalar subquery has a type |
Previous Message | Merlin Moncure | 2016-02-09 14:17:53 | Re: COALESCE requires NULL from scalar subquery has a type |