that routine was failing to perform analyze on
appqosdata.icmptraffic and its children due to another issue...
Regards,
Svetlin Manavski
On Fri, Oct 14, 2011 at 5:37 AM, Tom Lane wrote:
> Svetlin Manavski writes:
> > I am running 9.03 with the settings listed below. I have a proh
utovacuum_max_workers | 1
autovacuum_naptime | 1h
autovacuum_vacuum_threshold | 50
checkpoint_segments | 64
effective_cache_size | 3GB
fsync| on
lc_collate | C
lc_ctype | C
listen_addresses | *
log_
t;
1297270202368086000::bigint))"
" -> Index Scan using tcpsessiondata_67_pkey on
appqosdata.tcpsessiondata_67 sd (cost=0.00..11.51 rows=1 width=34) (actual
time=0.005..0.005 rows=0 loops=1)"
"Output: sd.detectorid, sd.createdtime,
sd.datafromsource, sd.datafromdestination, sd.packetsfromsource,
sd.packetsfromdestination"
"Index Cond: ((sd.detectorid >= 0) AND (sd.createdtime
>= 1297266601368086000::bigint) AND (sd.createdtime <
1297270202368086000::bigint))"
"Total runtime: 160114.339 ms"
The question is: why do we get a seq scan on appqosdata.tcpsessiondata_1 and
appqosdata.tcpsessiondata_2 even if the planner estimates correctly 1 row
out of millions could potentially be selected? As you can see ~90% of the
time is spent on those 2 partitions even if they are not apparently
different from any of the others.
I would appreciate any help with this issue.
Thank you,
Svetlin Manavski
ion. So I guess Pgpool-II in its
current state is good only for very simple applications, which are not
supposed to be reliable at all.
Thank you,
Svetlin Manavski
On Wed, Jun 29, 2011 at 8:14 PM, Greg Spiegelberg wrote:
>
> This does work however you'll need to add a little more to
he RDBMS)
Thank you,
Svetlin Manavski
Yes, confirmed that the problem is in the partitioned table.
Shaun, that solution is brilliant.
Thank you,
Svetlin Manavski
On Thu, Jun 16, 2011 at 7:36 PM, Shaun Thomas wrote:
> On 06/16/2011 12:25 PM, Magnus Hagander wrote:
>
> PostgreSQL 9.0 is unable to use an index scan to find m
n I do to make the first query use its index
on the primary key.
Thank you,
Svetlin Manavski
key in the other. That should be massively common in every non
trivial DB application. Maybe it does make sense to consider that specific
case in the planner, doesn't it?
Thank you,
Svetlin Manavski
On Tue, Jun 14, 2011 at 5:29 PM, Tom Lane wrote:
> Svetlin Manavski writes:
> &g
and SS.id >= 100100000::INT8 and SS.id <= 20010::INT8
in order to use the primary key on SS, even if it is absolutely clear that
"SD.detectorid = SS.detectorid and SD.sessionid = SS.id". Well I hope you
agree that repeating the same condition on SS seems very like giving a hint
to use the index there. But I feel very uncomfortable to use such an ugly
condition, especially knowing that I am doing it to "force an index". On the
other hand I am terrified that we may go in production for a seq scan on
hundreds of millions of rows just to extract 200 000.
Would you please explain that behavior and how would you suggest to proceed?
Thanks for any comments,
Svetlin Manavski
