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 n
On 24 July 2012 20:21, Richard Huxton wrote:
> On 24/07/12 12:14, Aleksei Arefjev wrote:
>
>> Hi,
>>
>> In statistical reports gathered by PgBadger on our PostgreSQL databases
>> almost always we have in "Queries that took up the most time" report
>> table information about transactions start tim
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.
Ca
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 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 table2 as a o
On Wed, Jul 25, 2012 at 1:40 AM, AI Rumman 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 caching than the oth
Aleksei Arefjev writes:
> On 24 July 2012 20:21, Richard Huxton 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 wondering exactly where/how the duration was mea
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
,COALESCE((sele
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 :
> Hi,
>
> Lacking index hints I have a bit of
Marcus Engene 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 selects looking s
Hi,
On Wednesday, July 25, 2012 04:56:20 PM Tom Lane wrote:
> Aleksei Arefjev writes:
> > On 24 July 2012 20:21, Richard Huxton 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 t
On 7/25/12 6:39 PM, Tom Lane wrote:
Marcus Engene 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.
On Tue, Jul 24, 2012 at 10:50 AM, Maciek Sakrejda 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 that it seems th
On Wed, Jul 25, 2012 at 3:45 PM, Merlin Moncure wrote:
> On Tue, Jul 24, 2012 at 10:50 AM, Maciek Sakrejda
> 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 ex
On Wed, Jul 25, 2012 at 2:17 PM, Vinicius Abrahao wrote:
> On Wed, Jul 25, 2012 at 3:45 PM, Merlin Moncure 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 that thread, this should get be
On Wed, Jul 25, 2012 at 4:26 PM, Merlin Moncure wrote:
> On Wed, Jul 25, 2012 at 2:17 PM, Vinicius Abrahao
> wrote:
>> On Wed, Jul 25, 2012 at 3:45 PM, Merlin Moncure wrote:
Note that it seems the preparing/planning interaction was not the
poster's actual problem, but it may have been
On Wed, Jul 25, 2012 at 2:59 PM, Vinicius Abrahao wrote:
> On Wed, Jul 25, 2012 at 4:26 PM, Merlin Moncure wrote:
>> On Wed, Jul 25, 2012 at 2:17 PM, Vinicius Abrahao
>> wrote:
>>> On Wed, Jul 25, 2012 at 3:45 PM, Merlin Moncure wrote:
> Note that it seems the preparing/planning interactio
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
> unfortunately postgres jdbc is bugged and does not honor the above for
> transaction control commands (begin, commit, etc). This patch
> http://treehou.se/~omar/postgresql-jdbc-8.4-701-pgbouncer_txn.patch
> will fix it, assuming it hasn't been fixed in recent postgres jdbc.
Looks like it's stil
On Wed, Jul 25, 2012 at 7:13 PM, Rural Hunter wrote:
> 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='"+col
20 matches
Mail list logo
