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
Dear Kevin,
Thanks for help!
Could you run this?:
set work_mem = '50MB';
set effective_cache_size = '3GB';
EXPLAIN ANALYZE your query
begin transaction;
drop index node_comment_statistics_node_comment_timestamp_idx;
EXPLAIN ANALYZE your query
rollback transaction;
set work_mem =
Jean-Michel Pouréj...@poure.com 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
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
Jean-Michel Pouréj...@poure.com 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=#
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
Jean-Michel Pouréj...@poure.com 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
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éj...@poure.com 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,
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
2009/8/27 Kevin Grittner kevin.gritt...@wicourts.gov:
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
Robert Haas robertmh...@gmail.com 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
Hello Guillaume!
Wed, 26 Aug 2009 23:59:25 +0200, you wrote:
On Wed, Aug 26, 2009 at 6:29 PM, Tom Lanet...@sss.pgh.pa.us 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).
2009/8/27 Gaël Le Mignot g...@pilotsystems.net:
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
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
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
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
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
bricklen brick...@gmail.com 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
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 t...@sss.pgh.pa.us wrote:
bricklen brick...@gmail.com writes:
Hi, I have a question about a db-wide vacuum that I am running that is
taking a
20 matches
Mail list logo
