Hello,
Sorry to send this off topic mail.
I sent a ontopic mail for three times over the whole day and none did
arrive.
No I changed my mail adress.
How can that be?
Sorry, next mail is on Topic.
Alexander
---(end of broadcast)---
TIP 3: if posting/
On Wed, Mar 10, 2004 at 17:25:49 -0500,
Randall Skelton <[EMAIL PROTECTED]> wrote:
>
> That would be ideal as it is theoretically possible for there to be
> missing rows due to sampling errors; nevertheless, a WHERE test doesn't
> seem obvious to me. Can you please post an example? The time
Randall Skelton <[EMAIL PROTECTED]> writes:
>> Couldn't you code this as a WHERE test on the timestamp?
> That would be ideal as it is theoretically possible for there to be
> missing rows due to sampling errors; nevertheless, a WHERE test doesn't
> seem obvious to me. Can you please post an ex
this will all be changed over this evening
On Wed, 10 Mar 2004, Bruno Wolff III wrote:
> I suggested that one of my coworkers pick up a copy of 7.4.2 and he
> had a problem locating it because the "latest" symbolic link still
> points to 7.4.1 and there is also no "v7.4.2" link as there is for 7
Maybe by using a sequence and a function.
The sequece to generate the row number.
The a function
1) to reset the sequence and
2) to perform a select with the first column nextval(seq) and the column the
timestamp
However, I am a newbie with PostgreSQL and I am not sure it this will work
cor
Bruno Wolff III wrote:
> I suggested that one of my coworkers pick up a copy of 7.4.2 and he
> had a problem locating it because the "latest" symbolic link still
> points to 7.4.1 and there is also no "v7.4.2" link as there is for 7.4.1.
> I had him get a copy by going into the source directory, bu
Randall Skelton <[EMAIL PROTECTED]> writes:
> Correction, I don't want to simply get the nth row, I want all rows
> that are divisible by n. Essentially, the timestamp is at a regular
> interval and I want a way of selecting rows at different sampling
> intervals.
Couldn't you code this as a W
On Mar 10, 2004, at 3:14 PM, Steve Wolfe wrote:
Before I shell out the $15k on the 4-way Opteron, I'm going to spend
some long, hard time looking for ways to make the system more
efficient.
However, after all that's already been done, I'm not optimistic that
it's
going to preclude needing the
I suggested that one of my coworkers pick up a copy of 7.4.2 and he
had a problem locating it because the "latest" symbolic link still
points to 7.4.1 and there is also no "v7.4.2" link as there is for 7.4.1.
I had him get a copy by going into the source directory, but I wasn't
sure if we were jump
> I to return a sequential row number beginning at 1?
>
> i.e.
>
> row| timestamp
> ---+
> 1 2004-02-01 23:15:00.824-05
> 2 2004-02-01 23:15:01.824-05
> 3 2004-02-01 23:15:02.824-05
> ...
>
> My reason for wanting row numbers is so I can use a 'MOD(row_
On Wed, Mar 10, 2004 at 06:33:41PM +0100, Paolo Tavalazzi wrote:
> Another question, in 7.4 GROUP BY clause not guarantee the ordering of result.
> Can I desable the new group by algorithm to maintain the coherence whit the programs
> that I have in production with pg_7.3
Uf you're expecting ord
> The only time I've seen high cpu and memory bandwidth load with
near-zero i/o
> load like you describe was on Oracle and it turned out to be an sql
> optimization problem.
> What caused it was a moderate but not very large table on which a very
> frequent query was doing a full table scan (= seq
Is there a way to return an integer row number for a query? Note that
there may be a large number of rows so I would rather not have joined
selects...
For a rather simple query:
SELECT timestamp from test
WHERE timestamp > '2004-02-02 04:15:00.00 +0'
ANDtimestamp < '2004-02-02 04:15:10.00
On Wed, Mar 10, 2004 at 18:33:41 +0100,
Paolo Tavalazzi <[EMAIL PROTECTED]> wrote:
>
> I don't know what to make, help me please!
>
> Another question, in 7.4 GROUP BY clause not guarantee the ordering of result.
> Can I desable the new group by algorithm to maintain the coherence whit the pro
Paolo Tavalazzi <[EMAIL PROTECTED]> writes:
> I have applied the procedure for fixing pg_statistic as you had said, but the
> result is the same!
Hm. It could be a planner bug. Can you reproduce the misbehavior if
you dump and load the tables into a fresh database? If so, could you
send me t
On Wed, 2004-03-10 at 15:30, Tom Lane wrote:
> "Fred Moyer" <[EMAIL PROTECTED]> writes:
> >> This is just a Seq Scan where a numeric field must be updated to
> >> NULL but if I run it you can see that this simple query takes
> >> forever (7628686.23 ms this is over 2 hours for only updating
> >> 74
> I wanted to do some quick load testing on a postgres database. Does
anyone
> have any tips on how to go about doing this?
> Thanks much.
Sure. Test after the manner in which the database is normally used,
and with "real-world" data.
I've seen far too many people "benchmark" a database sy
On Tue, 9 Mar 2004, Sally Sally wrote:
> I wanted to do some quick load testing on a postgres database. Does anyone
> have any tips on how to go about doing this?
> Thanks much.
If you just wanna beat the database a bit to test for reliability etc,
look at contrib/pgbench in the distro.
If you
> explain select * from foo where xmax not in
> (select transaction from pg_locks where transaction is not null);
Thanks a lot! This query is what i've been looking for.
Cheers!
Dexter Tad-y
---(end of broadcast)---
TIP 8: explain analyze is
Im trying to get a list of aggregate names. So i do "SELECT aggfnoid
FROM pg_aggregate" to get a list of Oid of the functions. But this
column seems to return names and not Oid's of the procs. Is this
normal, how can i get a loist of proc Oid's for the aggregtates?
thanks!
--
Alexander Cohen
h
On 3/10/04 10:03 AM, "Csaba Nagy" <[EMAIL PROTECTED]> wrote:
> It is the foreign key. Checking foreign keys in postgres is implemented
> by locking the corresponding row in the parent table. So if you have 2
> transactions inserting rows which reference the same keys in the parent
> table in rever
On Wed, 10 Mar 2004, Dexter Tad-y wrote:
> On Wed, 2004-03-10 at 23:08, Stephan Szabo wrote:
> > On Wed, 10 Mar 2004, Dexter Tad-y wrote:
> >
> > > Greetings,
> > > I need help in optimizing this query:
> > >
> > > select a.id, b.transaction from test as a left join pg_locks as b on
> > > a.xmax
Some additional info:
# select * from pg_class where relname = 'article_property_tree';
-[ RECORD 1 ]--
+---
relname| article_property_tree
relnamespace | 2200
reltype| 8349772
relowner | 1000
relam |
Frank van Vugt <[EMAIL PROTECTED]> writes:
>> This is consistent with the idea that pg_attribute_relid_attnum_index is
>> corrupted. I would suggest saving a copy of that file for postmortem
>> analysis and then trying to REINDEX pg_attribute.
> Uhm.. looking for a file named 8349771 located
Frank van Vugt <[EMAIL PROTECTED]> writes:
> At one point, I arrived at the following situation:
> psql:/home/data/megadump.sql:5169: WARNING: specified item offset is too
> large
> psql:/home/data/megadump.sql:5169: PANIC: failed to add item to the page
> for "pg_attribute_relid_attnum_index"
>
Have you run this update query again and again with vacuuming?
http://www.postgresql.org/docs/7.4/static/maintenance.html#ROUTINE-VACUUMING
If so, you might have millions and millions of dead tuples taking up
space and slowing things down. If you're running 7.4, install the
autovacuum daemon
> I'm sorry, I meant to say save a copy of
> pg_attribute_relid_attnum_index. The correct filename for it can be
> found via
> select relfilenode from pg_class where relname =
> 'pg_attribute_relid_attnum_index';
Got it, made a backup of the entire database as well. Since the db wasn't
filled ye
Alle 16:54, mercoledì 10 marzo 2004, hai scritto:
> Paolo Tavalazzi <[EMAIL PROTECTED]> writes:
> > I have two query that they are different only for order of the tables
> > in FROM lclause , but give back different query plan :
>
> Hm, seems like the planner is making wacko estimates in the second
On Wed, Mar 10, 2004 at 16:18:06 +0100,
Bjørn T Johansen <[EMAIL PROTECTED]> wrote:
> I am running 7.3.4 and I am thinking about upgrading to 7.4, so I was just
> wondering what pitfalls, caveats,etc I should know of?
Going from 7.3 to 7.4 shouldn't be a big deal. 7.4 pg_dumpall has some
improv
Paolo Tavalazzi <[EMAIL PROTECTED]> writes:
> I have two query that they are different only for order of the tables
> in FROM lclause , but give back different query plan :
Hm, seems like the planner is making wacko estimates in the second case.
You didn't say what data types are involved in this
On Wed, 3 Mar 2004, satish satish wrote:
> Hi,
>
> I am trying to do some reliability tests on postgre SQL. I have
> use-case where the power can go off abruptly. I initiated 10,000 insert
> operations and pulled out the cable in the middle. I had auto-commit
> option turned on. I observed 2
It is the foreign key. Checking foreign keys in postgres is implemented
by locking the corresponding row in the parent table. So if you have 2
transactions inserting rows which reference the same keys in the parent
table in reverse order, you get a deadlock.
This lock is admittedly too strong and n
32 matches
Mail list logo
