Mine is a single record INSERT, so no issues with plans :-) Little Java ETL
job.
Is there any setting I'd need to tweak assuming I'm using 150-200 of these
at once?
Cheers
Dave
On Wed, Apr 14, 2010 at 6:10 PM, Craig Ringer
wrote:
> On 15/04/10 04:49, Dave Crooke wrote:
>
>> Hi foilks
>>
>> I am
JmH writes:
> I am struggling to understand why for certain criteria that i supply for a
> query alters the the query plan. In my "good" case i can see that an index
> is used, in my bad case where i only change the text value of the criteria,
> but not the criteria itslef (ie change/add the condi
Hello,
I am struggling to understand why for certain criteria that i supply for a
query alters the the query plan. In my "good" case i can see that an index
is used, in my bad case where i only change the text value of the criteria,
but not the criteria itslef (ie change/add the conditions) a hbit
On 15/04/10 04:49, Dave Crooke wrote:
Hi foilks
I am using PG 8.3 from Java. I am considering a performance tweak which
will involve holding about 150 java.sql.PreparedStatment objects open
against a single PGSQL connection. Is this safe?
I know that MySQL does not support prepared statements /
Craig James wrote:
> On 4/7/10 5:47 PM, Robert Haas wrote:
> > On Wed, Apr 7, 2010 at 6:56 PM, David Rees wrote:
> >>> max_fsm_pages = 1600
> >>> max_fsm_relations = 625000
> >>> synchronous_commit = off
> >>
> >> You are playing with fire here. You should never turn this off unless
> >> you
Hi foilks
I am using PG 8.3 from Java. I am considering a performance tweak which will
involve holding about 150 java.sql.PreparedStatment objects open against a
single PGSQL connection. Is this safe?
I know that MySQL does not support prepared statements *per se*, and so
their implementation of
W dniu 14 kwietnia 2010 15:30 użytkownik Grzegorz Jaśkiewicz
napisał:
> That really sounds like hardware issue. The I/O causes the system to freeze
> basically.
> Happens sometimes on cheaper hardware.
>
Probably You have right because this is HS21 Blade Server. And as You
know blades are cheap a
"Kevin Grittner" wrote:
> (3) Try it like this (untested, so you may need to fix it up):
>
> explain analyze
> SELECT core_object.id
> from (SELECT id, city_id FROM "plugins_guide_address")
>"plugins_guide_address"
> JOIN "plugins_plugin_addr"
> ON ("plugins_plugin_addr"."addre
"Sabin Coanda" wrote:
> How do you explain the cost is about ten times lower in the 2nd
> query than the first ?
To elaborate on Pierre's answer:
In the first query, you scan the entire table and execute the "f1"
function on each row. In the second query you pass the entire table
just count
Krzysztof Kardas wrote:
> synchronous_commit = off
> This caused a monumental performance jump. From a machine that is
> utilized on 100%, machine is now sleeping and doing nothing. I
> have executed some sqls on huge tables like history and all has
> executed like lightning. Comparing to MySQ
That really sounds like hardware issue. The I/O causes the system to freeze
basically.
Happens sometimes on cheaper hardware.
Hi all.
Well I have used all Your recomendations but I still have no luck with
performance tunning. The machine has a moments thas was utilized in
100%. The problem was I/O on disks. CPU's were busy on system
interrupts.
I have started again to look of I/O performance tunning and I have changed
12 matches
Mail list logo
