>Josh Berkus
> > Treating the optimizer as a black box is something I'm very
> used to from
> > other RDBMS. My question is, how can you explicitly
> re-write a query now
> > to "improve" it? If there's no way of manipulating queries without
> > actually re-writing the optimizer, we're now in a po
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > while($howmany--) { push @morepgGurus, $pgGuru; }
>
> This is just wrong...
yeah, it would have been much clearer written as:
push @morepgGurus, ($pgGuru)x$howmany;
Or at least the perlish:
for (1..$howmany)
instead of C style while syntax.
O
my $pgGuru = "Tom Lane"; my @morepgGurus; my $howmany = 10;
while($howmany--) { push @morepgGurus, $pgGuru; }
This is just wrong...
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - [EM
Greg Stark wrote:
Bruno Wolff III <[EMAIL PROTECTED]> writes:
I have seen exactly this happen a number of times over the last several
years. However there is still only one Tom Lane implementing the
improvements.
Ob: Well clearly the problem is we need more Tom Lanes.
my $pgGuru = "Tom Lane";
Greg Stark <[EMAIL PROTECTED]> writes:
> Ob: Well clearly the problem is we need more Tom Lanes.
ObHHGReference: "Haven't you heard? I come in six-packs!"
regards, tom lane
---(end of broadcast)---
TIP 9: the planner will i
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> I have seen exactly this happen a number of times over the last several
> years. However there is still only one Tom Lane implementing the
> improvements.
Ob: Well clearly the problem is we need more Tom Lanes.
--
greg
---
Simon,
> Is the problem "a person interested" or is there another issue there?
IMHO, it's "a person interested".
> Treating the optimizer as a black box is something I'm very used to from
> other RDBMS. My question is, how can you explicitly re-write a query now
> to "improve" it? If there's no
> Bruno Wolff
> Simon Riggs <[EMAIL PROTECTED]> wrote:
> >
> > I guess what I'm saying is it's not how many people you've
> got working
> > on the optimizer, its how many accurate field reports of less-than
> > perfect optimization reach them. In that case, PostgreSQL
> is likely in a
> > better
On Wed, Apr 14, 2004 at 21:12:18 +0100,
Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> I guess what I'm saying is it's not how many people you've got working
> on the optimizer, its how many accurate field reports of less-than
> perfect optimization reach them. In that case, PostgreSQL is likely in
> Josh Berkus wrote:
> Unfortunately, these days only Tom and Neil seem to be
> seriously working on
> the query planner (beg pardon in advance if I've missed
> someone) so I think
> the real answer is that we need another person interested in
> this kind of
> optimization before it's going to get
On Mon, 2004-04-05 at 11:36, Josh Berkus wrote:
> Unfortunately, these days only Tom and Neil seem to be seriously working on
> the query planner (beg pardon in advance if I've missed someone)
Actually, Tom is the only person actively working on the planner --
while I hope to contribute to it in
On 5 Apr 2004 at 8:36, Josh Berkus wrote:
>
> Point taken, though, SQL Server has done a better job in opitimizing for
> "dumb" queries. This is something that PostgreSQL needs to work on, as is
> self-referential updates for large tables, which also tend to be really slow.
> Mind you, in
Gary Doades wrote:
Has anyone else done any comparative testing with the 2.6 kernel?
I know for a fact that certain stuff is recognized differently between
2.2, 2.4 and 2.6 kernels.
For example i have one box that i installed debian stable on that used a
2.2 kernel which automatically tuned on
On 4 Apr, Cott Lang wrote:
> On Sun, 2004-04-04 at 01:56, Gary Doades wrote:
>> Unfortunately I don't understand the question!
>>
>> My background is the primarily Win32. The last time I used a *nix OS
>> was about 20 years ago apart from occasional dips into the linux OS
>> over the past few y
Mike,
> I think it is also possible that Microsoft has more programmers working
> on tuning issues for SQL Server than PostgreSQL has working on the
> whole project.
Ah, but quantity != quality.Or they wouldn't be trolling our mailing lists
trying to hire PostgreSQL programmers for the SQL S
It says:
Using anticipatory io scheduler.
This then fits with the earlier post on other observations of up to 10
times better performance, which I what I was seeing in in certain
circumstances.
Cheers,
Gary.
On 4 Apr 2004 at 6:04, Cott Lang wrote:
> On Sun, 2004-04-04 at 01:56, Gary Doades
On Sun, 2004-04-04 at 01:56, Gary Doades wrote:
> Unfortunately I don't understand the question!
>
> My background is the primarily Win32. The last time I used a *nix OS
> was about 20 years ago apart from occasional dips into the linux OS
> over the past few years. If you can tell be how to fin
On 04/04/2004 09:56 Gary Doades wrote:
Unfortunately I don't understand the question!
My background is the primarily Win32. The last time I used a *nix OS
was about 20 years ago apart from occasional dips into the linux OS
over the past few years. If you can tell be how to find out what you want
I
On 3 Apr 2004 at 21:23, Mike Nolan wrote:
> > Almost any cross dbms migration shows a drop in performance. The engine
> > effectively trains developers and administrators in what works and what
> > doesn't. The initial migration thus compares a tuned to an untuned version.
>
> I think it is also
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Saturday, April 03, 2004 1:59 PM
> Subject: Re: [PERFORM] PostgreSQL and Linux 2.6 kernel.
>
>
> > Gary,
> >
> > > There are no indexes on the columns involved in the update, they are
> >
Unfortunately I don't understand the question!
My background is the primarily Win32. The last time I used a *nix OS
was about 20 years ago apart from occasional dips into the linux OS
over the past few years. If you can tell be how to find out what you want
I will gladly give you the informatio
s" <[EMAIL PROTECTED]>
To: "Gary Doades" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Saturday, April 03, 2004 1:59 PM
Subject: Re: [PERFORM] PostgreSQL and Linux 2.6 kernel.
> Gary,
>
> > There are no indexes on the columns involved in the update, the
> Almost any cross dbms migration shows a drop in performance. The engine
> effectively trains developers and administrators in what works and what
> doesn't. The initial migration thus compares a tuned to an untuned version.
I think it is also possible that Microsoft has more programmers working
On Sat, 2004-04-03 at 03:50, Gary Doades wrote:
> On 2 Apr 2004 at 22:36, [EMAIL PROTECTED] wrote:
>
> OK, some more detail:
>
> Before wiping 2.4 off my test box for the second time:
Perhaps I missed it, but which io scheduler are you using under 2.6?
---(end of bro
t;[EMAIL PROTECTED]>
To: "Gary Doades" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Saturday, April 03, 2004 1:59 PM
Subject: Re: [PERFORM] PostgreSQL and Linux 2.6 kernel.
> Gary,
>
> > There are no indexes on the columns involved in the update, they are
>
Following on from Josh's response and my previous reply on SQLServer planning.
The main problem query is this one:
SELECT VS.*,VL.TEL1,SC.CONTRACT_ID,SC.CONTRACT_REF, SC.MAX_HOURS,
SC.MIN_HOURS,
(SELECT COUNT(*) FROM TIMESHEET_DETAIL JOIN MAIN_ORDER ON
(MAIN_ORDER.ORDER_ID = TIMESHEET_DETAIL.
Sorry, I think I misread your post in my last reply. I thought you were still talking
about
the big update
The main thing I have noticed about SQLServer is it seems more willing to do hash or
merge joins than PostgreSQL. I have experimented with various postgresql.conf
parameters and even
Thanks,
I know about set showplan_text, but it is only the equivalent of explain,
not explain analyze. The graphical plan gives full statistics, runtime,
percentage cost, loop execution counts etc. which is much more useful.
I don't know of a way of getting the graphical plan content in text fo
Actually it hasn't been my experience either. Most of my queries against
the database, large and small are either a little quicker or no real
difference. I have only really noticed big differences under stress when
memory (RAM) is being squeezed. The main winner on 2.6 seems to be
write perform
Gary,
> There are no indexes on the columns involved in the update, they are
> not required for my usual select statements. This is an attempt to
> slightly denormalise the design to get the performance up comparable
> to SQL Server 2000. We hope to move some of our databases over to
> Pos
On 2 Apr 2004 at 22:36, [EMAIL PROTECTED] wrote:
OK, some more detail:
Before wiping 2.4 off my test box for the second time:
SQL Statement for update:
update staff_booking set time_from = r.time_from from order_reqt r where r.reqt_id =
staff_booking.reqt_id;
Explain: (on 2.4)
QUERY PLAN
The post was not intended to be content-rich, just my initial feedback
after only just switching to 2.6. Since I had largely given up on this
particular line of attack using 2.4 I didn't think to do a detailed analysis
at this time. I was also hoping that others would add to the discussion.
As
"Gary Doades" <[EMAIL PROTECTED]> writes:
> As a test in PosgreSQL I issued a statement to update a single column
> of a table containing 2.8 million rows with the values of a column in
> a table with similar rowcount. Using the above spec I had to stop the
> server after 17 hours. The poor thing
33 matches
Mail list logo
