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
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:
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 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, 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 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, 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
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
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
> 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
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
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
12 matches
Mail list logo
