2011/3/23 Tom Lane t...@sss.pgh.pa.us
Claudio Freire klaussfre...@gmail.com writes:
On Wed, Mar 23, 2011 at 5:29 PM, Josh Berkus j...@agliodbs.com wrote:
On 3/23/11 10:35 AM, Claudio Freire wrote:
* consider plan bailout: execute a tempting plan, if it takes too
long or its effective
You might take a look here:
http://archives.postgresql.org/pgsql-admin/2011-01/msg00050.php
My problem had to do with the speed of gettimeofday. You might want to do some
special setting regarding
your box's way of reading time for the hw clock.
Στις Thursday 24 March 2011 04:04:21 ο/η DM
Hi Cédric,
OK, sounds promising. But all of these improvements are for the postgres
developers.
For me as an administrator I can't do a thing right now. OK.
Thanks for you suggestions. I think for batchjobs other that just COPY they
could speed up the process quite well if now the backend
On Thu, Mar 24, 2011 at 11:11, Achilleas Mantzios
ach...@matrix.gatewaynet.com wrote:
My problem had to do with the speed of gettimeofday. You might want to do
some special setting regarding
your box's way of reading time for the hw clock.
Just for extra info, on x86, TSC is usually the fast
Στις Thursday 24 March 2011 13:39:19 ο/η Marti Raudsepp έγραψε:
On Thu, Mar 24, 2011 at 11:11, Achilleas Mantzios
ach...@matrix.gatewaynet.com wrote:
My problem had to do with the speed of gettimeofday. You might want to do
some special setting regarding
your box's way of reading time for
Hi,
I see my application creating temporary files while creating an index.
LOG: temporary file: path base/pgsql_tmp/pgsql_tmp7076.0, size 779853824
STATEMENT: CREATE INDEX IDX_LPA_LINKID ON NNDB.LPA (LINK_ID);
So I checked this again and raised afterwards maintenance_work_mem step by
step up
Uwe,
* Uwe Bartels (uwe.bart...@gmail.com) wrote:
So I checked this again and raised afterwards maintenance_work_mem step by
step up 64GB.
I logged in via psql, run the following statements
set maintenance_work_mem = '64GB';
I believe maintenance_work_mem suffers from the same problem that
OK. I didn't now that. Thanks for sharing that information.
Can anybody tell if we have this limitation on maintenance_work_mem as well?
Does anybody know of a solution out of that on Linux?
Or is there a dynamic way to put $PGDATA/base/pgsql_tmp into RAM without
blocking it completely like a ram
On 03/24/2011 09:40 AM, Uwe Bartels wrote:
Does anybody know of a solution out of that on Linux?
Or is there a dynamic way to put $PGDATA/base/pgsql_tmp into RAM without
blocking it completely like a ram disk?
We put this in our startup script just before starting the actual database:
for x
OK. sounds promising. On my machine this looks similar.
I'll try this.
Thanks,
Uwe
On 24 March 2011 16:14, Shaun Thomas stho...@peak6.com wrote:
On 03/24/2011 09:40 AM, Uwe Bartels wrote:
Does anybody know of a solution out of that on Linux?
Or is there a dynamic way to put
On 03/24/2011 10:28 AM, Uwe Bartels wrote:
OK. sounds promising. On my machine this looks similar.
I'll try this.
I just realized I may have implied that DBSHM automatically defaults to
/db/shm/pgsql_tmp. It dosen't. I also have this at the very top of our
/etc/init.d/postgresql script:
Em 24-03-2011 11:40, Uwe Bartels escreveu:
Or is there a dynamic way to put $PGDATA/base/pgsql_tmp into RAM without
blocking it completely like a ram disk?
Create a tablespace in a ram disk and set temp_tablespaces.
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent via
2011/3/24 Віталій Тимчишин tiv...@gmail.com:
2011/3/23 Tom Lane t...@sss.pgh.pa.us
Claudio Freire klaussfre...@gmail.com writes:
On Wed, Mar 23, 2011 at 5:29 PM, Josh Berkus j...@agliodbs.com wrote:
On 3/23/11 10:35 AM, Claudio Freire wrote:
* consider plan bailout: execute a tempting
This can se GUC-controllable. Like plan_safety=0..1 with low default value.
This can influence costs of plans where cost changes dramatically with small
table changes and/or statistics is uncertain. Also this can be used as
direct hint for such dangerous queries by changing GUC for
On Thu, Mar 24, 2011 at 5:30 PM, Nathan Boley npbo...@gmail.com wrote:
Another approach, that hasn't been suggested yet, is some Bayesian
update method. There, rather than calculating a specific parameter
value ( like ndistinct ), you try to store the entire distribution and
choose the plan
Thank you for your research on and posting on it, when I first encountered
this issue I saw your posting/research on this issue, this gave me a great
insight.
gettimeofday() on my new box is slow, after further research we found that,
when we set ACPI=Off, we got a good clock performance even the
16 matches
Mail list logo
