Hello,
Any news or ideas regarding this issue?
Thnx.
Ciao,
Gerhard
--
http://www.wiesinger.com/
On Sat, 4 Sep 2010, Gerhard Wiesinger wrote:
On Fri, 3 Sep 2010, Tom Lane wrote:
Gerhard Wiesinger li...@wiesinger.com writes:
8.3 query plans:
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 = ;
aza...@ang.com.pl 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)
-
Gaetano Mendola mend...@gmail.com 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.
[ Please keep the list cc'd ]
aza...@ang.com.pl 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
On 09/13/2010 04:44 PM, Tom Lane wrote:
Gaetano Mendola mend...@gmail.com 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
Gaetano Mendola mend...@gmail.com 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
On Mon, Sep 13, 2010 at 6:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Gaetano Mendola mend...@gmail.com 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
On Mon, Sep 13, 2010 at 2:39 AM, Gerhard Wiesinger li...@wiesinger.com 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,
On Mon, Sep 13, 2010 at 11:09 AM, Gaetano Mendola mend...@gmail.com wrote:
On Mon, Sep 13, 2010 at 6:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Gaetano Mendola mend...@gmail.com writes:
Of course I'm not suggesting to take away the sort by and give the user
an unsorted result, I'm asking why
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
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_tables
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 that one can
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 does not
14 matches
Mail list logo
