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
> 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
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
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
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: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 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 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 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.
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
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
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
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
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
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
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
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'
> ;
>
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
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
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
20 matches
Mail list logo
