Orion,
> Here's one good example of 7.3 beating 7.4 soundly:
> Again this could me some compile option since I built the 7.4 RPM
> from source and I got the 7.3 from Fedora or something to
> do with the Opteron architecture. (Yes the compiled postgres
> is 64 bit)
Need an EXPLAIN ANALYZE, not j
On Fri, Feb 06, 2004 at 02:36:57PM -0800, Josh Berkus wrote:
> Karl,
>
> Well, still with only 5 rows in the forumlog table you're not going get
> realistic results compared to a loaded database. However, you are making
> things difficult for the parser with awkward query syntax; what you curre
On Wed, 2004-02-04 at 21:27, Josh Berkus wrote:
Orion,
> I've done some testing of 7.3.4 vs 7.4.1 and found 7.4.1 to be 20%-30%
> slower than 7.3.4. Is this common knowledge or am I just unlucky with
> my query/data selection?
No, it's not common knowledge. It should be the other way aroun
On Fri, 2004-02-06 at 02:44, Hannu Krosing wrote:
> Christopher Browne kirjutas N, 05.02.2004 kell 07:32:
> > Oops! [EMAIL PROTECTED] (Orion Henry) was seen spray-painting on a wall:
> > > Oh... as a side note I'm happy to announce that the 2.6 Linux kernel
> > > has more than DOUBLED the speed of
On Fri, 2004-02-06 at 02:43, Hannu Krosing wrote:
> Orion Henry kirjutas N, 05.02.2004 kell 07:16:
> > I've done some testing of 7.3.4 vs 7.4.1 and found 7.4.1 to be 20%-30%
> > slower than 7.3.4. Is this common knowledge or am I just unlucky with
> > my query/data selection?
> >
> > Things of no
Karl,
Well, still with only 5 rows in the forumlog table you're not going get
realistic results compared to a loaded database. However, you are making
things difficult for the parser with awkward query syntax; what you currently
have encourages a sequential loop.
If there are potentially seve
On Fri, Feb 06, 2004 at 01:51:39PM -0800, Josh Berkus wrote:
> Karl,
>
> > SubPlan
> >-> Seq Scan on forumlog (cost=0.00..1.18 rows=1 width=8)
> > Filter: ((login = '%s'::text) AND (forum = '%s'::text) AND
> (number = $0))
>
> > Why is the subplan using a
Karl,
> SubPlan
>-> Seq Scan on forumlog (cost=0.00..1.18 rows=1 width=8)
> Filter: ((login = '%s'::text) AND (forum = '%s'::text) AND
(number = $0))
> Why is the subplan using a sequential scan? At minimum the index on the
> post number ("forumlog_numbe
I have two tables which have related selection data; they get updated
separately. One contains messages, the second an "index key" for each
user's viewing history.
When I attempt to use a select that merges the two to produce a "true or
false" output in one of the reply rows, I get a sequential s
First just wanted to say thank you all for the quick and helpful
answers. With all the input I know I am on the right track. With that
in mind I created a perl script to do my migrations and to do it based
on moving from a db name to a schema name. I had done alot of the
reading on convertin
Mike Nolan wrote:
Seriously, I am tired of this kind of question. You gotta get bold
enough to stand up in a "meeting" like that, say "guy's, you can ask me
how this compares to Oracle ... but if you're seriously asking me how
this compares to MySQL, call me again when you've done your homework"
On Thu, 2004-02-05 at 19:46, Slavisa Garic wrote:
> Hi,
>
> I have a quick question. In order to speed up insertion of large number of
> rows (100s of thousands) I replaced the INSERT with the COPY. This works
> fine but one question popped into my mind. Does copy updates indexes on
> that table i
I have some results with our DBT-2 (OLTP) workload on various linux-2.6
filesystems, if you'll find that interesting:
http://developer.osdl.org/markw/fs/dbt2_project_results.html
I've found JFS to perform similarly to ext2. Reiserfs isn't far behind.
XFS and ext3 fall off a bit. These re
On Fri, 6 Feb 2004, Bruno BAGUETTE wrote:
> > In addition to what Tom said, the row estimates look
> > suspiciously default. You mention vacuuming, but do you ever
> > analyze the tables?
>
> I run VACUUM FULL ANALYZE with the postgres user on all the PostgreSQL
> databases on the server, twice a
> In addition to what Tom said, the row estimates look
> suspiciously default. You mention vacuuming, but do you ever
> analyze the tables?
I run VACUUM FULL ANALYZE with the postgres user on all the PostgreSQL
databases on the server, twice a day, sometimes more.
> Also, what do you have sort_
re-Hello,
As suggested by Tom, I've removed the distinct and tried it's query :
levure=> explain analyze select initiale from (
levure(> select lower(substr(l_name,1,1)) as initiale from people
levure(> union all
levure(> select lower(substr(org_name,1,1)) as initiale from
organizations
lev
On Fri, 6 Feb 2004, Bruno BAGUETTE wrote:
> I was thinking that a index on lower(substr(l_name, 1, 1)) and another
> index on lower(substr(org_name, 1, 1)) should gives better performances.
> When I've to create theses two indexes, it seems like this is not
> allowed :
>
> levure=> CREATE INDEX f
"Bruno BAGUETTE" <[EMAIL PROTECTED]> writes:
> Do you see a way to get better performances with this query which takes
> currently 655.07 msec to be done.
> levure=> explain analyze SELECT distinct lower(substr(l_name, 1, 1)) AS
> initiale FROM people
> levure-> UNION
> levure-> SELECT distinct lo
Richard Huxton <[EMAIL PROTECTED]> writes:
> It's not entirely clear to me why this form is different from the other form
> though.
The code that checks for expressions containing unstable functions
doesn't look inside sub-selects. Arguably this is a bug, but people
were relying on that behavior
Christopher Browne kirjutas N, 05.02.2004 kell 07:32:
> Oops! [EMAIL PROTECTED] (Orion Henry) was seen spray-painting on a wall:
> > Oh... as a side note I'm happy to announce that the 2.6 Linux kernel
> > has more than DOUBLED the speed of all my Postgres queries over the
> > 2.4. =)
>
> I did so
Orion Henry kirjutas N, 05.02.2004 kell 07:16:
> I've done some testing of 7.3.4 vs 7.4.1 and found 7.4.1 to be 20%-30%
> slower than 7.3.4. Is this common knowledge or am I just unlucky with
> my query/data selection?
>
> Things of note that might matter: the machine is a dual Opteron 1.4GHz
> r
Hello,
Do you see a way to get better performances with this query which takes
currently 655.07 msec to be done.
levure=> explain analyze SELECT distinct lower(substr(l_name, 1, 1)) AS
initiale FROM people
levure-> UNION
levure-> SELECT distinct lower(substr(org_name, 1, 1)) AS initiale FROM
orga
On Friday 06 February 2004 07:19, Octavio Alvarez wrote:
> Hi!
>
>I'd like to know if this is expected behavior. These are two couples of
> queries. In each couple, the first one has a WHERE field = function()
> condition, just like the second one, but in the form WHERE field =
> (SELECT functi
Tomasz Myrta said:
> Dnia 2004-02-06 08:19, U¿ytkownik Octavio Alvarez napisa³:
>> In each couple, the first one has a WHERE field = function()
>> condition, just like the second one, but in the form WHERE field =
>> (SELECT function()). In my opinion, both should have the same execution
>> plan,
Hi!
I'd like to know if this is expected behavior. These are two couples of
queries. In each couple, the first one has a WHERE field = function()
condition, just like the second one, but in the form WHERE field =
(SELECT function()). In my opinion, both should have the same execution
plan, as t
25 matches
Mail list logo
