Doh!
Bad kharma. I apologize. Too late, and not enuf caffeine. I posted
here because this query is taking 2+ minutes on a production machine,
and under 4 seconds on a development machine.
For posterity sakes the seq scan is because of the distribution of
those values. GIL is in about 1/2
I thought this was related to the TYPE (ie, I could cast it using
something like: attr1=1::int8). However, I tried a few more values, and
the query planner is confusing me.
With these values, in the owner, I get a Seq Scan:
'GIL', '1122', '2305'
With these values, in the owner, I get an
Hi all, I'm having some confusion with the 7.4 query planner.
I have two identical queries, whereby the passed (varchar) parameter
appears to be the deciding factor between a sequential or an index scan.
IE, This query:
explain SELECT DISTINCT (a1.ENTRY_ID) AS retrieved FROM OS_CURRENTSTEP
AS a
On Fri, Sep 22, 2006 at 11:50:47PM +0200, Arjen van der Meijden wrote:
> If you're an AMD-fan, by all means, buy their products, those processors
> are indeed fast and you can build decent servers with them. But don't
> rule out Intel, just because with previous processors they were the
> slower
On 22-9-2006 22:34 Vivek Khera wrote:
so you think AMD is just sitting around twiddling their thumbs and
saying "well, time to give up since Intel is faster today". no. there
will be back-and forth between these two vendors to our benefit. I
would expect next-gen AMD chips to be faster than
Ok - so I have another mystery:I insert virtually the same rows into two different tables:trend=# insert into fish select 2, nextval('result_entry_order_seq'), property_id from property;INSERT 0 59913
trend=# insert into result_entry select 0, nextval('result_entry_order_seq'), property_id from pro
> On Fri, 2006-09-22 at 13:14 -0400, Charles Sprickman wrote:
> > Hi all,
> >
> > I still have an dual dual-core opteron box with a 3Ware 9550SX-12
> sitting
> > here and I need to start getting it ready for production. I also
have
> to
> > send back one processor since we were mistakenly sent two
On Sep 22, 2006, at 4:58 AM, nicky wrote:
till 100 simultaneous visitors, the Xeon performs 24% better with
MSQL 4.1.20, 30% better in MySQL 5.0.20a and 37% better in
PostgreSQL 8.2-dev. In short, the Socket F Opteron doesn't stand a
chance, although the Woodcrest scales better and has suc
On Fri, 2006-09-22 at 13:14 -0400, Charles Sprickman wrote:
> Hi all,
>
> I still have an dual dual-core opteron box with a 3Ware 9550SX-12 sitting
> here and I need to start getting it ready for production. I also have to
> send back one processor since we were mistakenly sent two. Before I do
Hi all,
I still have an dual dual-core opteron box with a 3Ware 9550SX-12 sitting
here and I need to start getting it ready for production. I also have to
send back one processor since we were mistakenly sent two. Before I do
that, I would like to record some stats for posterity and post to t
ahh good pointThanksOn 9/22/06, Tom Lane <[EMAIL PROTECTED]> wrote:
"Alex Turner" <[EMAIL PROTECTED]> writes:> Home come the query statistics showed that 229066 blocks where read given> that all the blocks in all the tables put together only total 122968?
You forgot to count the indexes. Also,
"Alex Turner" <[EMAIL PROTECTED]> writes:
> Home come the query statistics showed that 229066 blocks where read given
> that all the blocks in all the tables put together only total 122968?
You forgot to count the indexes. Also, the use of indexscans in the
mergejoins probably causes multiple re-
The query expain analyze looks like this:click-counter=# explain analyze select count(*) as count, to_char(date_trunc('day',c.datestamp),'DD-Mon') as day from impression c, url u, handle h where c.url_id=u.url_id and
c.handle_id=h.handle_id and h.handle like '1.19%' group by date_trunc('day',c
On Thu, Sep 21, 2006 at 11:05:39PM -0400, Bruce Momjian wrote:
> We tried posix_fadvise() during the 8.2 development cycle, but had
> problems as outlined in a comment in xlog.c:
>
> /*
> * posix_fadvise is problematic on many platforms: on older x86 Linux
> * it just dumps core, and
On Thu, Sep 21, 2006 at 08:46:41PM -0700, Luke Lonergan wrote:
> Mark,
>
> On 9/21/06 8:40 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
> > I'd advise against using this call unless it can be shown that the page
> > will not be used in the future, or at least, that the page is less useful
Hello Hannes,
The text above the pictures on page 13. Translated in my crappy english.
The confrontation between the Opteron and Woodcrest was inevitable in
this article, but who can add 1 and 1 should have known from the
previous two pages that it doesn't look that good for AMD . Under loads
Hi, Guy,
Guy Thornley wrote:
> Of course you could argue the OS should be able to detect this, and prevent
> it occuring anyway. I don't know anything about linux's behaviour in this
> area.
Yes, one can argue that way.
But a generic Algorithm in the OS can never be as smart as the
application
Try the translation ;)
http://tweakers.net/reviews/646/13
On 22-9-2006 10:32 Hannes Dorbath wrote:
A colleague pointed me to this site tomorrow:
http://tweakers.net/reviews/642/13
I can't read the language, so can't get a grip on what exactly the
"benchmark" was about.
Their diagrams show
A colleague pointed me to this site tomorrow:
http://tweakers.net/reviews/642/13
I can't read the language, so can't get a grip on what exactly the
"benchmark" was about.
Their diagrams show `Request per seconds'. What should that mean? How
many connections PG accepted per second? So they me
Hi, Markus,
Le mardi 19 septembre 2006 à 15:09 +0200, Markus Schaber a écrit :
> Hi, Jerome,
>
> Jérôme BENOIS wrote:
>
> >>> Now i Have 335 concurrent connections, i decreased work_mem parameter to
> >>> 32768 and disabled Hyper Threading in BIOS. But my CPU load is still
> >>> very important.
20 matches
Mail list logo
