On 13/09/10 19:48, Tom Lane wrote:
Gaetano Mendola writes:
Of course I'm not suggesting to take away the "sort by" and give the user
an unsorted result, I'm asking why the the optimizer in cases like:
select unique(a) from v_table_with_order_by;
doesn't takes away the "order by" insid
On Tue, Sep 14, 2010 at 2:07 AM, Gerhard Wiesinger wrote:
> Hello Merlin,
>
> Seems to be a feasible approach. On problem which might be that when
> multiple rows are returned that they are not ordered in each subselect
> correctly. Any idea to solve that?
>
> e.g.
> Raumsolltemperatur | Raumistte
> You could check for volatile functions. I think this could be done safely.
I don't think that's enough. A UDA like last() could have an immutable
sfunc, but still be sensitive to the sort order. I think you'd need
something like a special order-sensitive aggregate definition flag.
---
Maciek Sa
Hello,
I am relatively new to postgres (just a few months) so apologies if
any of you are bearing with me.
I am trying to get a rough idea of the amount of bang for the buck I
might see if I put in a connection pooling service into the enviroment
vs our current methodology of using persistent ope
I presume there is more usage of this view than just those 3 queries
(otherwise, for a start there would be no need for d, e, f in the view
definition)
Why not just rewrite these 3 queries to go directly off the main table? Or,
create a different view without the sort_by in its definition?
Or, if
On Tue, 2010-09-14 at 10:10 -0600, mark wrote:
> Hello,
>
> I am relatively new to postgres (just a few months) so apologies if
> any of you are bearing with me.
>
> I am trying to get a rough idea of the amount of bang for the buck I
> might see if I put in a connection pooling service into the
On Tue, Sep 14, 2010 at 12:10 PM, mark wrote:
> Hello,
>
> I am relatively new to postgres (just a few months) so apologies if
> any of you are bearing with me.
>
> I am trying to get a rough idea of the amount of bang for the buck I
> might see if I put in a connection pooling service into the en
On Tue, Sep 14, 2010 at 6:15 PM, Dave Crooke wrote:
> I presume there is more usage of this view than just those 3 queries
> (otherwise, for a start there would be no need for d, e, f in the view
> definition)
>
> Why not just rewrite these 3 queries to go directly off the main table? Or,
> create
On 9/14/10 9:10 AM, mark wrote:
Hello,
I am relatively new to postgres (just a few months) so apologies if
any of you are bearing with me.
I am trying to get a rough idea of the amount of bang for the buck I
might see if I put in a connection pooling service into the enviroment
vs our current m
On Tue, 14 Sep 2010, Merlin Moncure wrote:
On Tue, Sep 14, 2010 at 2:07 AM, Gerhard Wiesinger wrote:
Hello Merlin,
Seems to be a feasible approach. On problem which might be that when
multiple rows are returned that they are not ordered in each subselect
correctly. Any idea to solve that?
e.
On Tue, Sep 14, 2010 at 3:59 PM, Gerhard Wiesinger wrote:
> On Tue, 14 Sep 2010, Merlin Moncure wrote:
>
>> On Tue, Sep 14, 2010 at 2:07 AM, Gerhard Wiesinger
>> wrote:
>>>
>>> Hello Merlin,
>>>
>>> Seems to be a feasible approach. On problem which might be that when
>>> multiple rows are returne
On Tue, 14 Sep 2010, Merlin Moncure wrote:
np -- this felt particularly satisfying for some reason. btw, I think
you have some more low hanging optimization fruit. I think (although
it would certainly have to be tested) hiding your attribute
description under keyid is buying you nothing but head
12 matches
Mail list logo
