Bucky Jordan wrote:
Here's some simplistic performance numbers:
time bash -c "(dd if=/dev/zero of=bigfile count=125000 bs=8k && sync)"
Raid0 x 2 (2 spindles) ~138 MB/s on BSD
PE2950 FreeBSD6.1 i386 raid0 (2spindles):
time csh -c "(dd if=/dev/zero of=/data/bigfile count=125000 bs=8k && sync)
[EMAIL PROTECTED] writes:
> That makes sense. Would it be reasonable for the planner to eliminate
> plan considerations based on the existence of unique indexes, or is
> this a fundamentally difficult thing to get right in the general case?
The big obstacle to that at the moment is that we don't h
On Thu, Aug 17, 2006 at 09:21:33PM -0400, Tom Lane wrote:
> Another related form is
>
> neudb=> select uid, name from sm_change where system_dbid IN (select
> system_dbid from sm_system where uid =
> '2ff5942c.dd2911d5.ad56.08:00:09:fd:1b:da') and lower(name) =
> lower('markm-Q00855572');
> ...
On Thu, Aug 17, 2006 at 09:21:33PM -0400, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > I have two simple queries that do what I believe to be the exact same
> > thing.
> These are actually not equivalent per spec.
> ...
> This still isn't equivalent to the join: it'll return at most one copy
> o
[EMAIL PROTECTED] writes:
> I have two simple queries that do what I believe to be the exact same
> thing.
These are actually not equivalent per spec.
> neudb=> select uid, name from sm_change where system_dbid = (select
> system_dbid from sm_system where uid =
> '2ff5942c.dd2911d5.ad56.08:00:0
I have two simple queries that do what I believe to be the exact same
thing. I was surprised to see a reliable, and what I consider to be
significant (although not problematic for my application) difference
in execution time. It hints to me that PostgreSQL may be missing an
optimization opportunity
"Peter Hardman" <[EMAIL PROTECTED]> writes:
> On 17 Aug 2006 at 14:33, Tom Lane wrote:
>> I found a couple of minor planner problems, which I've repaired in CVS
>> HEAD. You might consider using TEXT columns instead of VARCHAR(n),
> As someone else suggested, these fields ought really to be CHAR
Peter, I compared these using the data you supplied on my PostgreSQL
8.1.4 system:
On Aug 17, 2006, at 12:09 PM, Scott Lamb wrote:
On Aug 16, 2006, at 3:51 PM, Tom Lane wrote:
/* Select all sheep who's most recent transfer was into the
subject flock */
SELECT DISTINCT f1.regn_no, f1.transf
On 17 Aug 2006 at 20:58, Peter Hardman wrote:
>
>
> On 16 Aug 2006 at 17:48, Peter Hardman wrote:
>
> > I'm in the process of migrating a Paradox 7/BDE 5.01 database from single-user
> > Paradox to a web based interface to either MySQL or PostgreSQL.
>
>
> I've uploaded my data to www.s
On 17 Aug 2006 at 14:33, Tom Lane wrote:
> I wrote:
> > Anywy, your point about the sort being redundant is a good one, and
> > offhand I'd have expected PG to catch that; I'll have to look into
> > why it didn't. But that's not going to explain a 10x speed
> > difference, because the sort isn't
On 16 Aug 2006 at 17:48, Peter Hardman wrote:
> I'm in the process of migrating a Paradox 7/BDE 5.01 database from
> single-user
> Paradox to a web based interface to either MySQL or PostgreSQL.
I've uploaded my data to www.shetland-sheep.org.uk/pgdata/sheep-flock.zip
The flock SSBXXX is t
On Aug 16, 2006, at 3:51 PM, Tom Lane wrote:
/* Select all sheep who's most recent transfer was into the
subject flock */
SELECT DISTINCT f1.regn_no, f1.transfer_date as date_in
FROM SHEEP_FLOCK f1 JOIN
/* The last transfer date for each sheep */
(SELECT f.regn_no, MAX(f.transfer_date)
I have no idea if there's a standard name or what it may be, but for
what it's worth, this sounds similar to the optimizations I wanted
for a different query:
http://archives.postgresql.org/pgsql-performance/2005-11/msg00037.php
1. Recognize that a term constant across the whole sort is
ir
I wrote:
> Anywy, your point about the sort being redundant is a good one, and
> offhand I'd have expected PG to catch that; I'll have to look into
> why it didn't. But that's not going to explain a 10x speed
> difference, because the sort isn't 90% of the runtime.
I dug into this using some made
> MSSQL can give either a graphical query plan or a text-based
> one similar to PG. There's no way that I've found to get the
> equivalent of an EXPLAIN ANALYZE, but I'm by no means an MSSQL guru.
SET STATISTICS IO ON
SET STATISTICS PROFILE ON
SET STATISTICS TIME ON
//Magnus
MSSQL can give either a graphical query plan or a text-based one similar
to PG. There's no way that I've found to get the equivalent of an
EXPLAIN ANALYZE, but I'm by no means an MSSQL guru.
To get a neat-looking but not very useful graphical query plan from the
Query Analyzer tool, hit .
To get
"Peter Hardman" <[EMAIL PROTECTED]> writes:
> I wonder whether Paradox and MySQL are just not doing the sort (this
> seems to be what eats up the time), since the output of the subquery
> is in fact already in the proper order.
MSSQL (from the other thread). I feel fairly safe in assuming that
My
Hi, Peter,
Peter Hardman wrote:
> select version() returns
>
> PostgreSQL 8.1.3 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.4.2
> (mingw-special)
That looks correct.
I also presume that your environment is not as fragile wr/t connecting
do wrong databases, compared to debian with thei
On 17 Aug 2006 at 12:11, Markus Schaber wrote:
> Hi, Peter,
>
> Peter Hardman wrote:
>
> >> BTW, are you *sure* you are testing PG 8.1? The "Subquery Scan f2" plan
> >> node looks unnecessary to me, and I'd have expected 8.1 to drop it out.
> >> 8.0 and before would have left it in the plan tho
Hi, Peter,
Peter Hardman wrote:
>> BTW, are you *sure* you are testing PG 8.1? The "Subquery Scan f2" plan
>> node looks unnecessary to me, and I'd have expected 8.1 to drop it out.
>> 8.0 and before would have left it in the plan though. This doesn't make
>> all that much difference performanc
On 16 Aug 2006 at 18:51, Tom Lane wrote:
> "Peter Hardman" <[EMAIL PROTECTED]> writes:
> > I'm in the process of migrating a Paradox 7/BDE 5.01 database from
> > single-user
Arjen van der Meijden has proposed a very elegant query in another post.
> What I find interesting though is that it s
On 17 Aug 2006 at 10:00, Mario Weilguni wrote:
> not really sure if this is right without any testdata, but isn't that what
> you
> want?
>
> CREATE index foo on sheep_flock (flock_no);
>
> SELECT DISTINCT on (f1.transfer_date) f1.regn_no, f1.transfer_date as date_in
> FROM SHEEP_FLOCK f1
> W
22 matches
Mail list logo
