On 24.07.2012 14:51, Laszlo Nagy wrote:
* UFS is not journaled.
There is journal support for UFS as far as i know. Please have a look
at the gjournal manpage.
Yes, but gjournal works for disk devices.
That isn't completly correct! gjournal works with all GEOM-devices,
which could be
Tom Lane, 24.07.2012 19:12:
Well, it would only help if you're running a PG version that's new
enough to recognize the NOT EXISTS as an anti-join; and even then,
it's possible that joining on a tid column forecloses enough plan
types that you don't get any real benefit. But I'm just guessing.
Thanks. I missed to add the trigger.
Now I added it, but still without partition taking less time compared to
with partition query.
*With partition :- *
explain analyze
select *
from table1 as c
inner join table2 as a on c.crmid = a.activityid and deleted = 0
where module ='Leads'
;
hi al,
On Jul 25, 2012, at 10:40 AM, AI Rumman rumman...@gmail.com wrote:
Thanks. I missed to add the trigger.
Now I added it, but still without partition taking less time compared to with
partition query.
With partition :-
explain analyze
select *
from table1 as c
inner join
On Wed, Jul 25, 2012 at 1:40 AM, AI Rumman rumman...@gmail.com wrote:
Thanks. I missed to add the trigger.
Now I added it, but still without partition taking less time compared to
with partition query.
Based on the different times on Seq Scan on table2, it looks like
one query has better
Aleksei Arefjev aleksei.aref...@nordicgaming.com writes:
On 24 July 2012 20:21, Richard Huxton d...@archonet.com wrote:
I'm not sure if I'm reading this right, but are there more than 48 million
BEGINs that took 0s each (presumably rounded down) and then a handful
taking about 0.8s?
I'm
Hi,
Lacking index hints I have a bit of a problem with a slow select.
select
pic.objectid as pic_objectid
,pu.objectid as pu_objectid
,ppcr.preproc_me as pul_preproc_me
,pp.price_amount as pp_price_amount
,pim.aut_item_container as pim_aut_item_container
Hello
you have too slow merge join
maybe you have bloated item_common_pkey or item_common relations -
can you try reindex or vacuum full
you use random_page_cost = 1.0 - it can be source of bad plan
Regards
Pavel Stehule
2012/7/25 Marcus Engene meng...@engene.se:
Hi,
Lacking index hints
Marcus Engene meng...@engene.se writes:
Lacking index hints I have a bit of a problem with a slow select.
I don't think you need index hints. What you probably do need is to
increase join_collapse_limit and/or from_collapse_limit to deal with
this complex query as a whole.
There are several
Hi,
On Wednesday, July 25, 2012 04:56:20 PM Tom Lane wrote:
Aleksei Arefjev aleksei.aref...@nordicgaming.com writes:
On 24 July 2012 20:21, Richard Huxton d...@archonet.com wrote:
I'm not sure if I'm reading this right, but are there more than 48
million BEGINs that took 0s each
On 7/25/12 6:39 PM, Tom Lane wrote:
Marcus Engene meng...@engene.se writes:
Lacking index hints I have a bit of a problem with a slow select.
I don't think you need index hints. What you probably do need is to
increase join_collapse_limit and/or from_collapse_limit to deal with
this complex
On Tue, Jul 24, 2012 at 10:50 AM, Maciek Sakrejda m.sakre...@gmail.com wrote:
This may be another issue of the problem discussed here:
http://postgresql.1045698.n5.nabble.com/avoid-prepared-statements-on-complex-queries-td4996363.html
(Kris Jurka explains the crux of it in that thread).
Note
On Wed, Jul 25, 2012 at 3:45 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Tue, Jul 24, 2012 at 10:50 AM, Maciek Sakrejda m.sakre...@gmail.com
wrote:
This may be another issue of the problem discussed here:
On Wed, Jul 25, 2012 at 2:17 PM, Vinicius Abrahao vinnix@gmail.com wrote:
On Wed, Jul 25, 2012 at 3:45 PM, Merlin Moncure mmonc...@gmail.com wrote:
Note that it seems the preparing/planning interaction was not the
poster's actual problem, but it may have been yours. As Tom Lane notes
in
On Wed, Jul 25, 2012 at 4:26 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Wed, Jul 25, 2012 at 2:17 PM, Vinicius Abrahao vinnix@gmail.com
wrote:
On Wed, Jul 25, 2012 at 3:45 PM, Merlin Moncure mmonc...@gmail.com wrote:
Note that it seems the preparing/planning interaction was not the
On Wed, Jul 25, 2012 at 2:59 PM, Vinicius Abrahao vinnix@gmail.com wrote:
On Wed, Jul 25, 2012 at 4:26 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Wed, Jul 25, 2012 at 2:17 PM, Vinicius Abrahao vinnix@gmail.com
wrote:
On Wed, Jul 25, 2012 at 3:45 PM, Merlin Moncure
Why not just use simple Statement instead of PreparedStatement and
construct the SQL with concated string or StringBuilder? like this:
int col1=xxx;
String col2=;
String sql=select * from table where col1=+col+ and col2='+col2+';
δΊ 2012/7/26 3:59, Vinicius Abrahao ει:
On Wed, Jul 25, 2012
17 matches
Mail list logo
