Hi,
PostgreSQL 8.4.2 / default_statistics_target = 300
I have a strange problem for a bad choose of indexes.
client=# \d ct13t
Table "public.ct13t"
Column | Type | Modifiers
+--+---
ct12emp04 | integer | not null
ct03emp01 | integer
Hi Tom,
2010/3/19 Tom Lane :
> Alexandre de Arruda Paes writes:
>> My question: if the cost is exactly the same, why PG choose the index
>> ict13t2 on ct13t and apply a filter instead use the primary key ?
>
> Why shouldn't it, if the estimated costs are the sa
Hi,
PG 8.4.4
I have an strange problem:
carmen=# VACUUM FULL verbose tp93t;
INFO: vacuuming "public.tp93t"
INFO: "tp93t": found 0 removable, 71984 nonremovable row versions in 17996
pages
DETAIL: 70632 dead row versions cannot be removed yet.
Nonremovable row versions range from 1848 to 2032
ead row versions cannot be removed yet.
Nonremovable row versions range from 1853 to 2029 bytes long.
There were 210 unused item pointers.
(...)
2010/8/17 Scott Marlowe
> On Tue, Aug 17, 2010 at 2:28 PM, Alexandre de Arruda Paes
>
> wrote:
>
> So what do:
> select *
_24274_index" now contains 0 row versions in 1 pages
DETAIL: 0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
VACUUM
2010/8/18 Tom Lane
> Alexandre de Arruda Paes writes:
> > I know the problem with VACUUM FULL and bloated In
you have a
> >> non-stop transactional activity in your PG database???... (24/7 OLTP
> >> for ex.)
> >>
> >> Rgds,
> >> -Dimitri
> >>
> >>
> >> On 8/19/10, Kevin Grittner wrote:
> >>> Alexandre de Arruda Paes wrot
Hi,
First, sorry to compare Post with other database system, but I know nothing
about Oracle...
This customer have an application made with a framework thats generates the
SQL statements (so, We can't make any query optimizations) .
We did the following tests:
1) Postgresql 9.3 and Oracle 10 in
st regards,
Alexandre
2015-08-05 14:24 GMT-03:00 Kevin Grittner :
> Alexandre de Arruda Paes wrote:
>
> > We did the following tests:
> >
> > 1) Postgresql 9.3 and Oracle 10 in a desktop machine(8 GB RAM, 1 SATA
> disk,Core i5)
> > 2) Postgresql 9.3 in a server + F
Hi Andreas,
Same plan in 9.5, but the execution time was greater than 9.3 (maybe need
some tunning):
postgres@hw-prox01-fac:~/PG95$ /usr/PG95/bin/psql copro95 -p 5444
psql (9.5alpha1)
Type "help" for help.
copro95=# explain (analyze,buffers) SELECT
T1.fr13baixa,T1.fr13dtlanc,T2.fr02empfo,COALESC
>
>
> The query in question is likely performing badly because of this:
>
> -> Seq Scan on fr13t1 (cost=0.00..25072.50
> rows=311800 width=21) (actual time=0.007..115.766 rows=311800 loops=1)
>Filter: (fr01codemp = '1'::smallint)
>
>
>
> Notice the seq scan on t1 instead of the index scan on t1_a_idx.
>
> A way around this is to manually push the predicate down into the subquery:
>
> explain select t2.a,s.sumv from (select a,sum(v) sumv from t1 where t1.a
> <= 1 group by a) s inner join t2 on t2.a = s.a where t2.a <= 1;
>
Hi,
In the query below, the planner choose an extreme slow mergejoin(380
seconds). 'Vacuum analyze' can't help.
If I CLUSTER (or recreate) table ES09T1, the planner choose a faster
hashjoin (about 10 seconds). But, obviously, I can't do that with the users
connected.
After some time after cluster(
aps a partial index,
table partitioning, etc) ???
Best regards,
Alexandre
2016-04-01 10:17 GMT-03:00 David Rowley :
> On 1 April 2016 at 15:44, Alexandre de Arruda Paes
> wrote:
>
>> In the query below, the planner choose an extreme slow mergejoin(380
>> seconds). 'Vacu
I will be very happy with a tool(or a stats table) that shows the most
searched values from a table(since a statistic reset). i.e.:
table foo (id int, year int)
top 3 searched value for year field: 2017(500x), 2016(300x), 2015(55x)
With this info we can create partial indexes or do a table part
14 matches
Mail list logo
