Am 27.09.2012, 02:04 Uhr, schrieb Jeff Janes :
On Wed, Sep 26, 2012 at 1:21 PM, hubert depesz lubaczewski
wrote:
On Wed, Sep 26, 2012 at 02:38:09PM -0400, Robert Sosinski wrote:
The first query shows a cost of 190,169.55 and runs in 199,806.951 ms.
When I disable nested loop, I get a cost of
Hello,
i have a problem with relatively easy query.
EXPLAIN ANALYZE SELECT content.* FROM content JOIN blog ON blog.id =
content.blog_id JOIN community_prop ON blog.id = community_prop.blog_id JOIN
community ON community.id = community_prop.id WHERE community.id IN (33, 55,
61, 1741, 75, 90, 1
Kiriakos Tsourapas, 25.09.2012 13:01:
Thank you,
I will take this into consideration, since upgrading to 9 will be much harder I
assume...
I think an upgrade from 8.3 to 8.4 was "harder" due to the removal of a lot of
implicit type casts.
8.4 to 9.x shouldn't be that problematic after all (
On Fri, Sep 28, 2012 at 11:33 AM, M. D. wrote:
> On 09/28/2012 09:57 AM, David Boreham wrote:
>>
>> On 9/28/2012 9:46 AM, Craig James wrote:
>>>
>>> Your best warranty would be to have the confidence to do your own
>>> repairs, and to have the parts on hand. I'd seriously consider
>>> putting you
Greetings.
I have a small monitoring query on the following tables:
select relname,relpages,reltuples::numeric(12) from pg_class where relname
in ('meta_version','account') order by 1;
relname| relpages | reltuples
--+--+---
account | 3235 |197723
Hi Tom, v9.2.1 looks good!
Aggregate (cost=420808.99..420809.00 rows=1 width=0) (actual
time=147.345..147.345 rows=1 loops=1)
-> Nested Loop Semi Join (cost=0.00..420786.71 rows=8914 width=0)
(actual time=13.847..147.219 rows=894 loops=1)
-> Index Scan using notes_retirement_date_
Shaun Thomas writes:
> The first part of the question stands, though... Why isn't the optimizer
> substituting these values? a.created_date should be exactly equivalent
> to '2012-05-05', but it's clearly not being treated that way.
No version of Postgres has ever substituted constants in the w
Hi Tom, thank you very much. I'll load these tables onto a 9.2 instance and
report back.
Matt
On Fri, Sep 28, 2012 at 2:44 PM, Tom Lane wrote:
> Matt Daw writes:
> > Howdy, I've been debugging a client's slow query today and I'm curious
> > about the query plan. It's picking a plan that hashes
Matt Daw writes:
> Howdy, I've been debugging a client's slow query today and I'm curious
> about the query plan. It's picking a plan that hashes lots of rows from the
> versions table (on v9.0.10)...
> EXPLAIN ANALYZE
> SELECT COUNT(*) FROM notes a WHERE
> a.project_id = 114 AND
> EXISTS (
>
On 09/28/2012 03:35 PM, Tom Lane wrote:
9.1.what? For me, 8.2.23 and 9.1.6 produce the same plan and just
about the same runtime for your query 1.
I withdraw that part of my question. I apparently didn't look closely
enough at the actual output. I was basing the version assumption on the
qu
Howdy, I've been debugging a client's slow query today and I'm curious
about the query plan. It's picking a plan that hashes lots of rows from the
versions table (on v9.0.10)...
EXPLAIN ANALYZE
SELECT COUNT(*) FROM notes a WHERE
a.project_id = 114 AND
EXISTS (
SELECT 1 FROM note_links b
WH
Shaun Thomas writes:
> I ran into this while we were working on an upgrade project. We're
> moving from 8.2 (don't ask) to 9.1, and started getting terrible
> performance for some queries. I've managed to boil it down to a test case:
9.1.what? For me, 8.2.23 and 9.1.6 produce the same plan and
Hey guys,
I ran into this while we were working on an upgrade project. We're
moving from 8.2 (don't ask) to 9.1, and started getting terrible
performance for some queries. I've managed to boil it down to a test case:
create temp table my_foo as
select a.id, '2012-01-01'::date + (random()*365)
On 09/28/2012 09:57 AM, David Boreham wrote:
On 9/28/2012 9:46 AM, Craig James wrote:
Your best warranty would be to have the confidence to do your own
repairs, and to have the parts on hand. I'd seriously consider
putting your own system together. Maybe go to a few sites with
pre-configured m
On 9/28/2012 9:46 AM, Craig James wrote:
Your best warranty would be to have the confidence to do your own
repairs, and to have the parts on hand. I'd seriously consider
putting your own system together. Maybe go to a few sites with
pre-configured machines and see what parts they use. Order th
On 9/27/2012 1:56 PM, M. D. wrote:
>>
>> I'm in Belize, so what I'm considering is from ebay, where it's unlikely
>> that I'll get the warranty. Should I consider some other brand rather? To
>> build my own or buy custom might be an option too, but I would not get any
>> warranty.
Your best warra
On Thu, Sep 27, 2012 at 03:50:33PM -0500, Shaun Thomas wrote:
> On 09/27/2012 03:44 PM, Scott Marlowe wrote:
>
> >This 100x this. We used to buy our boxes from aberdeeninc.com and got
> >a 5 year replacement parts warranty included. We spent ~$10k on a
> >server that was right around $18k from d
I think the best advice I can think of is to go back to the basics. Tools
like sar and top and look at logs. Changing random settings on both the
client and server seems like guessing. I find it unlikely that the changes
you made (jdbc and shared buffers) had the effects you noticed. Determine
On machine 1 - a table that contains between 12 and 18 million rows
On machine 2 - a Java app that calls Select * on the table, and writes it
into a Lucene index
Originally had a fetchSize of 10,000 and would take around 38 minutes for 12
million, 50 minutes for 16ish million to read it all & writ
John Nash wrote:
> We have being doing some testing with an ISD transaction and we had
> some problems that we posted here.
>
> The answers we got were very kind and useful but we couldn't solve the
> problem.
Could you refer to the threads so that you don't get the same advice again?
> We have
On 09/27/2012 10:22 PM, M. D. wrote:
On 09/27/2012 02:55 PM, Scott Marlowe wrote:
On Thu, Sep 27, 2012 at 2:46 PM, M. D. wrote:
select item.item_id,item_plu.number,item.description,
(select number from account where asset_acct = account_id),
(select number from account where expense_acct = acc
21 matches
Mail list logo
