Chew,
First off, this isn't the appropriate list. So if you have follow-up
questions, please post them to NOVICE or GENERAL.
> I have checked the ftp sites for Postgresql software under the binary/RPMS
> folder and discovered that v7.3.2 is not available for redhat 9.0
> Only v7.3.3 and above i
Oops! [EMAIL PROTECTED] was seen spray-painting on a wall:
> We installed our Postgresql package from the RH CDROM v9.
> The version is v7.3.2
>
> Is there a compatibility matrix for Postgresql vs OS that I can verify?
>
> I have checked the ftp sites for Postgresql software under the
> binary/RPMS
I tried to delete the user from the pg_user but couldnt. This username is
being duplicated so we have the same 2 records.
What is the cause ? Is it due to memory or wrong configuration?
Maybe it's an index corruption issue.
Try reindexing the pg_shadow table, based on the instructions here:
http
Hi
I tried to delete the user from the pg_user but couldnt. This username is
being duplicated so we have the same 2 records.
What is the cause ? Is it due to memory or wrong configuration?
Thank you,
REgards.
[EMAIL PROTECTED] writes:
> When I do a SELECT * FROM pg_shadow, I can have more than one user
> with the same id. This caused the pg_dump to fail.
> I read that it happened in v7.1.2 and I am currently using v7.3.2
This is *real* hard to believe. Versions 7.2 and later have a unique
index on
Tom Lane <[EMAIL PROTECTED]> writes:
> (I'd argue that the SQL generator is broken anyway ;-) if it generates
> such horrible conditions as that. Or maybe the real problem is that
> the database schema is a mess and needs rethinking.)
I had the same reaction when I first saw those queries. But
Maybe you could delete one of the users from the pg_shadow table, do the
dump and then after the dump is restored, recreate the dropped user (and
it will get a new sysid)
Chris
[EMAIL PROTECTED] wrote:
Hi
Hi
When I do a SELECT * FROM pg_shadow, I can have more than one user with the same id.
This caused the pg_dump to
fail.
Rob Nagler <[EMAIL PROTECTED]> writes:
> One of the reason postgres is faster on the q1-4 is that postgres
> supports OFFSET/LIMIT, and oracle doesn't. q7 and q8 are the queries
> that I've referred to recently (avg of group by).
Well the way to do offset/limit in Oracle is:
SELECT *
FROM (
Hi
We installed our Postgresql package from the RH CDROM v9.
The version is v7.3.2
Is there a compatibility matrix for Postgresql vs OS that I can verify?
I have checked the ftp sites for Postgresql software under the binary/RPMS
folder and discovered that v7.3.2 is not available for redhat 9.0
Rob,
> q5 and q6 are too complex to discuss here, but the fundamental issue
> is the order in which postgres decides to do things. The choice for
> me is clear: the developer time trying to figure out how to make the
> planner do the "obviously right thing" has been too high with
> postgres. The
[EMAIL PROTECTED] writes:
> I really not intend to start a flame war here but i am genuinely
> seeking help to retain PostgreSQL as my database for my RT system.
If there are things that can be discovered to feed back to the RT
developers to improve PostgreSQL's usefulness as a data store for RT,
Rob Nagler <[EMAIL PROTECTED]> writes:
> q5 and q6 are too complex to discuss here,
How do you expect us to get better if you don't show us the problems?
BTW, have you tried any of this with a 7.4beta release? Another project
that I'm aware of saw several bottlenecks in their Oracle-centric code
Greg Stark writes:
> > > SELECT a, (SELECT name FROM t2 WHERE t2.f2 = t1.f2)
> > > FROM t1
> > > GROUP BY f2
> >
> > This doesn't solve the problem. It's the GROUP BY that is doing the
> > wrong thing. It's grouping, then aggregating.
>
> But at least in the form above it will consider usin
<[EMAIL PROTECTED]> writes:
> Actually PostgreSQL is at par with MySQL when the query is being
> Properly Written(simplified)
These are not the same query, though. Your original looks like
SELECT DISTINCT main.*
FROM Groups main , Principals Principals_1, ACL ACL_2
WHERE
((ACL_2.RightName =
I've done a better controlled series of tests where I restore the
database before each test and have grabbed sar and oprofile data:
http://developer.osdl.org/markw/dbt2-pgsql/176/
- load of 100 warehouses
- metric 1234.52
http://developer.osdl.org/markw/dbt2-pgsql/177/
- l
> On Thu, 30 Oct 2003 [EMAIL PROTECTED] wrote:
>
>> >> So its not just PostgreSQL that is suffering from the bad SQL but MySQL also.
>> >> But the
>> >> question is my does PostgreSQL suffer so badly ?? I think not all developers
>> >> write very
>> >> nice SQLs.
>> >>
>> >> Its really sad to s
On Thu, 30 Oct 2003 [EMAIL PROTECTED] wrote:
> >> So its not just PostgreSQL that is suffering from the bad SQL but MySQL also.
> >> But the
> >> question is my does PostgreSQL suffer so badly ?? I think not all developers
> >> write very nice
> >> SQLs.
> >>
> >> Its really sad to see that a
ok this time it constructs a query which puts 7.3.4 on a infinite loop
but 7.4b5 is able to come out of it.
since it may be of interest to the pgsql people i am Ccing it to the
pgsql-performance list i hope its ok.
Pgsql 7.3.4 on an endless loop:
SELECT DISTINCT main.* FROM Tickets main
>> So its not just PostgreSQL that is suffering from the bad SQL but MySQL also. But
>> the
>> question is my does PostgreSQL suffer so badly ?? I think not all developers write
>> very nice
>> SQLs.
>>
>> Its really sad to see that a fine peice of work (RT) is performing sub-optimal
>> becoz
>
>
>
> On Thu, Oct 30, 2003 at 01:15:44AM +0530, [EMAIL PROTECTED] wrote:
>> Actually PostgreSQL is at par with MySQL when the query is being Properly
>> Written(simplified)
>>
>> In mysql:
>> mysql> SELECT DISTINCT main.* FROM Groups main join Principals Principals_1
>> using(id) join
>> ACL
> So its not just PostgreSQL that is suffering from the bad SQL but
> MySQL also. But the question is my does PostgreSQL suffer so badly
> ?? I think not all developers write very nice SQLs.
>
> Its really sad to see that a fine peice of work (RT) is performing
> sub-optimal becoz of malformed S
Actually PostgreSQL is at par with MySQL when the query is being Properly
Written(simplified)
like below
rt3=# SELECT DISTINCT main.* FROM Groups main join Principals Principals_1
using(id) join ACL
ACL_2 on (ACL_2.PrincipalId = Principals_1.id) WHERE ((ACL_2.RightName =
'OwnTicket')OR
Dear PostgreSQL gurus,
I really not intend to start a flame war here but i am genuinely
seeking help to retain PostgreSQL as my database for my RT
system.
Few months back i had posted regarding lowering of column names in SQL
being passed to RDBMS by DBIx::SearchBuilder , looks like it was contr
On Wed, 2003-10-29 at 09:03, Robert Treat wrote:
> I just noticed on one of my tables I have the following two indexes:
>
> Indexes: entity_watch_map_pkey primary key btree (entity_id, watch_id),
> ewm_entity_id btree (entity_id),
>
>
> I can't think of why the second index is there, as
On Wednesday 29 October 2003 2:23 pm, Tom Lane wrote:
> Your initial message stated plainly that the problem was in INSERTs;
> it's not surprising that you got unhelpful advice.
But perhaps my use of the term "insert" to describe upload was a very bad call
given the domain of the list...
I assu
Damien Dougan <[EMAIL PROTECTED]> writes:
> Now, our problem seems to be the delays introduced by reading from the
> public views.
Your initial message stated plainly that the problem was in INSERTs;
it's not surprising that you got unhelpful advice.
> View definition:
> [ huge view full of LEFT
I just noticed on one of my tables I have the following two indexes:
Indexes: entity_watch_map_pkey primary key btree (entity_id, watch_id),
ewm_entity_id btree (entity_id),
I can't think of why the second index is there, as ISTM there is no
instance where the first index wouldn't be us
On Wed, 29 Oct 2003 09:47:28 +0800
Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
> >>Just loaded up delicious 7.4b5 and wow...
> >>
> >>sort_mem 8192: 137038ms [lots of tmp file activity]
> >>sort_mem 256000: 83109ms
> >
> 1. A full ANALYZE
> 2. A delete all from pg_statistic
>
I had prev
On Monday 27 October 2003 8:12 pm, Tom Lane wrote:
> Damien Dougan <[EMAIL PROTECTED]> writes:
> > Has anyone any ideas as to what could be causing the spiraling
> > performance?
>
> You really haven't provided any information that would allow anything
> but guesses, but I'll guess anyway: poor pla
30 matches
Mail list logo
