If I run " dd if=/dev/zero bs=1024k of=file count=1000 " iostat shows me:
Device:tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 671.5088.00113496.00176 226992
However postgres 8.3.7 doing a bulk data write (a slony slave, doing
inserts a
Yeah, there's a lot. Way more than I am accustomed to seeing from the same
command on the previous server.
On Thu, Aug 27, 2009 at 4:05 PM, Tom Lane wrote:
> bricklen writes:
> > Hi, I have a question about a db-wide vacuum that I am running that is
> > taking a much longer time than normal. We
bricklen writes:
> Hi, I have a question about a db-wide vacuum that I am running that is
> taking a much longer time than normal. We switched over to our warm standby
> server today -- which is virtually identical to the source db server -- and
> I initiated a "vacuum analyze verbose". Normally t
Hi, I have a question about a db-wide vacuum that I am running that is
taking a much longer time than normal. We switched over to our warm standby
server today -- which is virtually identical to the source db server -- and
I initiated a "vacuum analyze verbose". Normally this process wouldn't take
On Wed, 26 Aug 2009, Hrishikesh (??? ) wrote:
key = {device_id (uint64), identifier (uint32), sub_identifier (uint32),
unix_time} (these four taken together are unique)
You should probably tag these fields as NOT NULL to eliminate needing to
consider that possibility during query
Le jeudi 27 août 2009 à 14:05 -0400, Tom Lane a écrit :
> tom lane
Dear Tom,
Why is the query planner displaying ::integer
What does it mean?
Kind regards,
Jean-Michel
signature.asc
Description: Ceci est une partie de message numériquement signée
Le jeudi 27 août 2009 à 13:35 -0400, Robert Haas a écrit :
> SELECT MIN(tid), MAX(tid), SUM(1) FROM term_node;
> SHOW default_statistics_target;
SELECT MIN(tid), MAX(tid), SUM(1) FROM term_node;
6;56;67479
SHOW default_statistics_target;
100
For information, if some hackers are interested and th
2009/8/27 Gaël Le Mignot :
> The weird thing was that with the default of 100 for statistics
> target, it was worse than when we moved back to 10. So I didn't try
> with 1000, but I should have.
When you have so much data and a statistics target so low, you can't
expect the sample taken
Hello Guillaume!
Wed, 26 Aug 2009 23:59:25 +0200, you wrote:
> On Wed, Aug 26, 2009 at 6:29 PM, Tom Lane wrote:
>> g...@pilotsystems.net (=?iso-8859-1?Q?Ga=EBl?= Le Mignot) writes:
>>> So it seems it was quite wrong about estimated matching rows (192
>>> predicted, 10222 reals).
>>
>> Yu
Robert Haas writes:
> By the way, why does EXPLAIN not display the name of the table as well
> as the index when it performs a bitmap index scan?
Because that plan node is not in fact touching the table. The table
name is shown in the BitmapHeapScan node that *does* touch the table.
2009/8/27 Kevin Grittner :
> It is *possible* that if you boost your default_statistics_target and
> run ANALYZE (or VACUUM ANALYZE), it will recognize that it isn't a
> good idea to read backwards on that index. I would try it and see, if
> that's practical for you.
I notice this in one of the p
Le jeudi 27 août 2009 à 11:36 -0500, Kevin Grittner a écrit :
> It is *possible* that if you boost your default_statistics_target and
> run ANALYZE (or VACUUM ANALYZE), it will recognize that it isn't a
> good idea to read backwards on that index. I would try it and see, if
> that's practical for
Jean-Michel Pouré wrote:
> Also, just a short notice that this SELECT returns no result.
Once you posted EXPLAIN ANALYZE results, that was clear because actual
rows on the top line is zero.
> You were right: adding LIMIT 1 changes speed from O.090 ms to 420
> ms.
In summary, what's happenin
Le jeudi 27 août 2009 à 09:52 -0500, Kevin Grittner a écrit :
> Just to get another data point, what happens if you run the same query
> without taking the index out of the picture, but without the LIMIT or
> OFFSET clauses? An EXPLAIN ANALYZE of that would help understand it
> more fully.
Also,
Jean-Michel Pouré wrote:
> ... Index Cond: ((tid)::integer = 3)
> ... Index Cond: ((n.vid)::integer = (tn.vid)::integer)
> ... Index Cond: ((ncs.nid)::integer = n.nid)
> Total runtime: 0.092 ms
Sorry, but I just had to point that out.
I feel much better now. ;-)
> Does it mean my index
Le jeudi 27 août 2009 à 09:16 -0500, Kevin Grittner a écrit :
> Then you need to use a better tool to run it.
Understood, thanks.
cms=# set work_mem = '50MB';
SET
cms=# set effective_cache_size = '1GB';
SET
cms=# begin transaction;
BEGIN
cms=# drop index node_comment_statistics_node_comment_time
>Jean-Michel Pouré wrote:
> Does not show any result because of ROLLBACK;
Then you need to use a better tool to run it. For example, in psql:
test=# create table t2 (c1 int not null);
CREATE TABLE
test=# insert into t2 select * from generate_series(1,1);
INSERT 0 1
test=# create uniqu
Le jeudi 27 août 2009 à 09:01 -0500, Kevin Grittner a écrit :
> The type is always put in there so that you can see what it's doing;
> it doesn't reflect anything which is actually taking any time.
My query plan for the same query is:
"Aggregate (cost=12.75..12.76 rows=1 width=0) (actual time=0.
Jean-Michel Pouré wrote:
> Still casting.
For about the tenth time on the topic -- YOUR PROBLEM HAS NOTHING
WHATSOEVER TO DO WITH CASTING! Let that go so you can look for the
real problem.
Just as an example, look at this closely:
test=# create table t2 (c1 int not null primary key);
NOTICE:
Dear Kevin,
Thanks for help!
Could you run this?:
>
> set work_mem = '50MB';
> set effective_cache_size = '3GB';
> EXPLAIN ANALYZE
> begin transaction;
> drop index node_comment_statistics_node_comment_timestamp_idx;
> EXPLAIN ANALYZE
> rollback transaction;
set work_mem = '50MB';
set effect
Le mercredi 26 août 2009 à 18:03 -0500, Kevin Grittner a écrit :
> That's part of your problem.
Sorry, I wrote that too quickly.
My configuration is (Quad core, 8Gb):
shared_buffers = 2GB (WAS 1GB)
temp_buffers = 128MB (modified after reading your message)
work_mem = 512MB (modified after readin
21 matches
Mail list logo
