On Tue, Apr 10, 2012 at 04:59, Jeff Janes wrote:
> On Fri, Apr 6, 2012 at 3:09 PM, Kim Hansen wrote:
>
>> I have run the queries a few times in order to warm up the caches, the
>> queries stabilise on 20ms and 180ms.
>
> My first curiosity is not why the estimate is too
Hi all
On Fri, Apr 6, 2012 at 19:11, Jeff Janes wrote:
> On Wed, Apr 4, 2012 at 6:47 AM, Kim Hansen wrote:
>> Hi All
>>
>> I have a query where the planner makes a wrong cost estimate, it looks
>> like it underestimates the cost of a "Bitmap Heap Scan" compa
On Thu, Apr 5, 2012 at 17:34, Kevin Grittner
wrote:
> Kim Hansen wrote:
>
>> I have a query where the planner makes a wrong cost estimate, it
>> looks like it underestimates the cost of a "Bitmap Heap Scan"
>> compared to an "Index Scan".
>
>&
Fast (21ms): http://explain.depesz.com/s/ThQ
I have run "VACUUM FULL VERBOSE ANALYZE". I have configured
shared_buffers and effective_cache_size, that didn't solve my problem,
the estimates was kept the same and both queries got faster.
What can I do to fix the cost estimate?
Regards,
Ki
Hi.
First extremely thanks for your works about postgresql .
I wonder that after executing 'vaccumdb -z' some other process can not
read their own msg queue during 2 ~ 3 minuts.
vaccum executed every hour. and The processes have not any relations between
postgreql.
Is it possible ?
Thank you Marti,
I will go with the ``reduced number of matched rows'' and naturally be waiting
for postgres 9.1 expectantly.
Kind regards,
Kim
On 2011-02-15 22:13, Marti Raudsepp wrote:
On Tue, Feb 15, 2011 at 21:33, Kim A. Brandt wrote:
removing the ORDER BY worked. But I
-02-15 15:49, Shaun Thomas wrote:
On 02/15/2011 08:23 AM, Kim A. Brandt wrote:
does `postgres (PostgreSQL) 8.4.5' use the LIMIT of a query when it
is run on a partitioned-table or am I doing something wrong? It looks
as if postgres queries all partitions and then LIMITing the records
after
key on unitstat_y2010m04 unitstat
(cost=0.00..11840.93 rows=6194 width=193) (actual time=52.735..17302.361
rows=21936 loops=1)
Index Cond: (((nodeid)::text = 'abcd'::text) AND (ts
> '2010-01-01 00:00:00'::timestamp without time zone) AND (ts < '2011-02-15
15:00:00'::timestamp without time zone))
-> Index Scan using
fki_unitstat_y2010m03_nodeid_ts_fkey on unitstat_y2010m03 unitstat
(cost=0.00..11664.36 rows=6101 width=194) (actual time=66.613..17541.374
rows=15471 loops=1)
Index Cond: (((nodeid)::text = 'abcd'::text) AND (ts
> '2010-01-01 00:00:00'::timestamp without time zone) AND (ts < '2011-02-15
15:00:00'::timestamp without time zone))
Total runtime: 205855.569 ms
Regards,
Kim
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
number of stats table entries times the number
of pg_class rows; in other words O(N^2) if the stats collector's
information is reasonably complete. Replace list searching with a
hash table to bring it back to O(N) behavior. Per report from kim
at myemma.com. Back-patch as far as 8.1; 8.
Following this there was a phase were
it did a lot of seeks and reads on files under pg_clog, and it was while
doing this (or perhaps it had finished whatever it wanted with clogs) it
dropped into the send()/SIGUSR1 loop that goes for another several minutes.
Kim
Tom Lane wrote:
I wro
continue to see some of the other problems I mentioned as side-notes,
we'll build some information on those and pass it along...
Thanks so much!
Kim
Tom Lane wrote:
Kim <[EMAIL PROTECTED]> writes:
We were running on 8.1.1 previous to upgrading to 8.2, and yes, we
definitely h
plete install, any tests you can think of that may further
narrow things down for us?
relkind | count
-+
v | 1740
t | 49986
c | 4
S | 57
r | 108689
i | 374723
(6 rows)
Tom Lane wrote:
Kim <[EMAIL PROTECTED]> writes:
.
OS: Solaris 10
write transactions/hr: 1.5 million
size of pg_class: 535,226
number of relations: 108,694
Thanks to all,
Kim
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
We dropped into single user mode and ran reindex system - it was my
understanding this would reindex them all, including shared catalogs -
but perhaps not?
Kim
Tom Lane wrote:
Kim <[EMAIL PROTECTED]> writes:
The current dump query running:
SELECT t.tableoid, t.oid, t.reln
X4100 XL
2x AMD Opteron Model 275 dual core procs
8GB of ram
(this server overheated & crashed due to a cooling problem at the
hosting service)
On top of a:
Sun Storedge 6130
14x 146GB Drives in a Raid 5
Brocade 200E switches
Emulex 4gb HBAs
(this server had no known problems)
Thanks in advance,
Kim Hatcher <http://www.myemma.com>
Quoting Tom Lane <[EMAIL PROTECTED]>:
> Kim Bisgaard <[EMAIL PROTECTED]> writes:
> > W.r.t. your rewrite of the query, I get this "ERROR: could not devise a
> > query plan for the given query" but no further details - I will try google
>
> Which PG v
Quoting Tom Lane <[EMAIL PROTECTED]>:
> Kim Bisgaard <[EMAIL PROTECTED]> writes:
> > SELECT station_id, timeobs,temp_grass, temp_dry_at_2m
> > FROM temp_dry_at_2m a
> > FULL OUTER JOIN temp_grass b
> > USING (station_id, timeob
Hi Bruno,
Thanks for the moral support! I feel so too - but I am confident it will
show up soon.
W.r.t. your rewrite of the query, I get this "ERROR: could not devise a
query plan for the given query" but no further details - I will try google
Regards,
Kim.
Bruno Wolff III w
re virtually identical??
I have tried to formulate the problem with left joins, but this demands
from me that I know which table has all the values (and thus has to go
first), and in practice no such table excists.
TIA,
Kim Bisgaard.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
btree (station_id, timeobs)
The difference between the two queries is if a (station_id,timeobs) row
is missing in one table, then the first returns one record(null,9.3)
while the second return no records.
Regards,
Kim Bisgaard.
Tom Lane wrote:
Kim Bisgaard <[EMAIL PROTECTED]> writes:
Hi,
Look for my comments further down...
John A Meinel wrote:
Kim Bisgaard wrote:
Hi,
I'm having problems with the query optimizer and FULL OUTER JOIN on
PostgreSQL 7.4. I cannot get it to use my indexes with full outer joins.
I might be naive, but I think that it should be possible?
I hav
.00..6.00 rows=1 width=16) (actual time=13.694..13.698 rows=1 loops=1)
Index Cond: (("outer".station_id = a.station_id) AND (a.timeobs = '2004-01-01 00:00:00'::timestamp without time zone))
Total runtime: 79.340 ms
(9 rows)
If further info like EXPLAIN VERBOSE is useful please say so and I will
provide it.
Thanks in advance!
Kim Bisgaard.
22 matches
Mail list logo
