Hi!
At 14:16 22.08.00 -0400, you wrote:
>Jan Wieck <[EMAIL PROTECTED]> writes:
> > I haven't looked at the code, but pg_class only has a boolean
> > telling if a class has rules or not. Could it be that adding
> > more rules (or dropping just a few instead of all) doesn't
> >
Jan Wieck <[EMAIL PROTECTED]> writes:
> I haven't looked at the code, but pg_class only has a boolean
> telling if a class has rules or not. Could it be that adding
> more rules (or dropping just a few instead of all) doesn't
> update the pg_class tuple, thus the syscache for
Stephan Szabo wrote:
> Wierd, I've not seen that behavior really, although I've never
> done time sensitive stuff. It might be the time before the
> shared cache updates? Not sure really. If you do the rule
> inline with your inserts (rather than a second transaction)
> does it still wait?
Wierd, I've not seen that behavior really, although I've never
done time sensitive stuff. It might be the time before the
shared cache updates? Not sure really. If you do the rule
inline with your inserts (rather than a second transaction)
does it still wait?
Stephan Szabo
[EMAIL PROTECTED]
O
Hi!
At 08:18 18.08.00 -0700, you wrote:
[...]
>I didn't try with vacuum, I just did a table lock and that
>seemed to still hang the inserts with two tables, so I figured
>maximum safety was adding the third table. If it works with two
>that's much cooler. Was this with real data or just a smal
On Fri, 18 Aug 2000, Joerg Hessdoerfer wrote:
> Good idea - I immediately tested it - rules rule! That seems to work perfectly,
> and the client doesn't even see it happen (except for 'selects', one would
> have to setup
> a rule to return something meaningful then...).
>
> I did:
> Two tables,
Hi!
At 11:57 18.08.00 +0100, you wrote:
>I'm not familiar with rules. Could you please post the SQL for creating
>the rule
>that you've created?
Here we go (if memory serves ;-)
create table a ( num int4, name text );
create table b ( num int4, name text );
rule to insert into b instead of a:
I'm not familiar with rules. Could you please post the SQL for creating the rule
that you've created?
I going to make such a setup in the near future and this seems to .
Joerg Hessdoerfer wrote:
> Hi!
>
> Thanks all for your input...
>
> At 09:15 17.08.00 -0700, you wrote:
> [...]
> > > Questio
hi!
At 11:38 17.08.00 -0700, you wrote:
>Hi All.
>
>Shouldn't Postgres block while vacuuming, and then
>continue inserting starting where it left off? Is the
>time lag too much?
For me - yes. My app can accept some hundredes of ms time lag - not
seconds or, like with a VACUUM, minutes (I've see
Hi!
Thanks all for your input...
At 09:15 17.08.00 -0700, you wrote:
[...]
> > Question: would it work to use a transaction to perform the rename?
> >
> > i.e.: continuous insert into table 'main' from client.
> >
> > From somewhere else, execute:
> >
> > begin;
> > alter table main rename to v
Poul L. Christiansen writes:
> Isn't easier to reduce the table every day and make a daily vacuum which only
> lasts a few seconds?
I doubt that it would last just a few seconds. From my experience, VACUUM
on large tables can sap your I/O subsystem, slowing down overall
performance for everyone
Hi All.
Shouldn't Postgres block while vacuuming, and then
continue inserting starting where it left off? Is the
time lag too much?
I am curious because I am going to build a similar app
soon, basically parsing and inserting log file
entries.
W
--- Stephan Szabo <[EMAIL PROTECTED]>
wrote:
>
On Thu, 17 Aug 2000, Joerg Hessdoerfer wrote:
> Hi!
>
> I have an application, where I have to insert data into a table at several
> rows per second, 24 hours a day, 365 days a year.
>
> After some period (a week, maybe a month) the data will be reducted to some
> degree and deleted from the t
Isn't easier to reduce the table every day and make a daily vacuum which only
lasts a few seconds?
Joerg Hessdoerfer wrote:
> Hi!
>
> I have an application, where I have to insert data into a table at several
> rows per second, 24 hours a day, 365 days a year.
>
> After some period (a week, mayb
14 matches
Mail list logo
