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 | Raumisttemperatur
Value from time 1 | Value from time 2
Value from time 2 |
Excerpts from Josh Berkus's message of lun sep 13 20:53:51 -0400 2010:
>
> > If you select from pg_stat_user_tables, the counters should be
> > reasonably close unless your default_statistics_target is way off and
> > then pg_class.reltuples would be wrong.
>
> At least in 8.3, running ANALYZE do
Josh Berkus writes:
> I've been looking at pg_stat_user_tables (in 8.3, because of a project I
> have), and it appears that autovacuum, and only autovaccum, updates the
> data for this view.
Um ... it updates the last_autovacuum and last_autoanalyze columns,
but the others are not its responsibil
> If you select from pg_stat_user_tables, the counters should be
> reasonably close unless your default_statistics_target is way off and
> then pg_class.reltuples would be wrong.
At least in 8.3, running ANALYZE does not update pg_stat_user_tables in
any way. Does it in later versions?
--
On Mon, 2010-09-13 at 16:47 -0700, Josh Berkus wrote:
> On 9/13/10 4:41 PM, Joshua D. Drake wrote:
> > On Mon, 2010-09-13 at 16:06 -0700, Josh Berkus wrote:
> >> All,
> >>
> >> I've been looking at pg_stat_user_tables (in 8.3, because of a project I
> >> have), and it appears that autovacuum, and o
On 9/13/10 4:41 PM, Joshua D. Drake wrote:
> On Mon, 2010-09-13 at 16:06 -0700, Josh Berkus wrote:
>> All,
>>
>> I've been looking at pg_stat_user_tables (in 8.3, because of a project I
>> have), and it appears that autovacuum, and only autovaccum, updates the
>> data for this view. This means tha
On Mon, 2010-09-13 at 16:06 -0700, Josh Berkus wrote:
> All,
>
> I've been looking at pg_stat_user_tables (in 8.3, because of a project I
> have), and it appears that autovacuum, and only autovaccum, updates the
> data for this view. This means that one can never have data in
> pg_stat_user_table
All,
I've been looking at pg_stat_user_tables (in 8.3, because of a project I
have), and it appears that autovacuum, and only autovaccum, updates the
data for this view. This means that one can never have data in
pg_stat_user_tables which is completely up-to-date, and if autovacuum is
off, the vi
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 2:39 AM, Gerhard Wiesinger wrote:
> Hello,
>
> Any news or ideas regarding this issue?
hm. is retooling the query an option? specifically, can you try converting
CREATE OR REPLACE VIEW log_entries AS
SELECT
l.id AS id,
l.datetime AS datetime,
l.tdate AS tdate,
l
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
[ Please keep the list cc'd ]
writes:
>> What exactly are those join key values, and what are the min/max values
>> in bug_t2?
> min of Bug_t1.id = 42,
> max of Bug_t1.id = 393065,
> min of Bug_t2.id = 352448,
> max of Bug_t2.id = 388715,
> select count(id) from bug_t2
> 29
> select count
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
writes:
> Merge Join (cost=18.90..20.85 rows=1 width=8) (actual time=614.912..614.912
> rows=0 loops=1)
>Merge Cond: (rr.id = ze.id)
>-> Index Scan using bug_t2_i1 on bug_t2 rr (cost=0.00..17893.49
> rows=278417 width=4) (actual time=0.023..351.945 rows=278417 loops=1)
>-> Sort (c
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 = "";
18 matches
Mail list logo
