On 09/23/2010 05:05 AM, gnuo...@rcn.com wrote:
> Spoken like a dyed in the wool COBOL coder. The RM has no need for order;
> it's set based. I've dabbled in PG for some time, and my sense is
> increasingly that PG developers are truly code oriented, not database (set)
> oriented.
That's a b
On Thu, Sep 23, 2010 at 7:51 AM, wrote:
> Not insulting, just amused bemusement. PG portrays itself as the best OS
> database, which it may well be. But it does so by stressing the
> row-by-agonizing-row approach to data. In other words, as just a record
> paradigm filestore for COBOL/java/
I can't tell if you meant for this to be insulting or my reading it that way is
wrong, but it certainly wasn't put in a helpful tone. Let me summarize for
you. You've been told that putting ORDER BY into a view is a generally poor
idea anyway, that it's better to find ways avoid this class of
On Wed, Sep 22, 2010 at 11:05 PM, wrote:
> Spoken like a dyed in the wool COBOL coder. The RM has no need for order;
> it's set based. I've dabbled in PG for some time, and my sense is
> increasingly that PG developers are truly code oriented, not database (set)
> oriented.
I'm struggling t
On Wed, Sep 22, 2010 at 10:01 PM, Greg Smith wrote:
> gnuo...@rcn.com wrote:
>>
>> Spoken like a dyed in the wool COBOL coder. The RM has no need for order;
>> it's set based. I've dabbled in PG for some time, and my sense is
>> increasingly that PG developers are truly code oriented, not databa
gnuo...@rcn.com wrote:
Spoken like a dyed in the wool COBOL coder. The RM has no need for order; it's set based. I've dabbled in PG for some time, and my sense is increasingly that PG developers are truly code oriented, not database (set) oriented.
I can't tell if you meant for this to be
Original message
>Date: Wed, 22 Sep 2010 20:54:22 -0400
>From: pgsql-performance-ow...@postgresql.org (on behalf of Robert Haas
>)
>Subject: Re: [PERFORM] Useless sort by
>To: Gaetano Mendola
>Cc: Tom Lane ,pgsql-performance@postgresql.org
>
>On Mon,
On Mon, Sep 13, 2010 at 1:09 PM, Gaetano Mendola wrote:
> I see your point, but some functions like: unique, count are not affected
> by the order of values fed, and I don't think either that unique has to
> give out the unique values in the same fed order.
Gee, I'd sure expect it to.
--
Rober
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
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
> 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 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 Mon, Sep 13, 2010 at 11:09 AM, Gaetano Mendola wrote:
> On Mon, Sep 13, 2010 at 6:48 PM, 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:
>>
>>> s
> I see your point, but some functions like: unique, count are not affected
> by the order of values fed, and I don't think either that unique has to
> give out the unique values in the same fed order.
Sure. You'd need additional metadata about which aggregates care about
sort order and which don
On Mon, Sep 13, 2010 at 6:48 PM, 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 aw
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" inside the view and puts it back "rewrit
On 09/13/2010 04:44 PM, Tom Lane wrote:
> Gaetano Mendola writes:
>> because of that sort in the view definition the first query above
>> takes not less than 3 seconds. I have solved this performance issue
>> removing the sort from the view definition and putting it in the
>> select reducing the t
Gaetano Mendola writes:
> because of that sort in the view definition the first query above
> takes not less than 3 seconds. I have solved this performance issue
> removing the sort from the view definition and putting it in the
> select reducing the time from > 3secons to < 150ms.
> Can not the
Hi all,
I have a view v_table defined as following:
select a,b,c,d,e,f
from t_table
sort by a,b,c;
the usage pattern of this view is the following:
select distinct(a) from v_table;
select distinct(b) from v_table where a = "XXX";
select distinct(c) from v_table where a = "XXX" and b = "";
19 matches
Mail list logo
