> On 18 Aug 2003 at 16:19, Erwin Brandstetter wrote:
> An example database that demonstrates the usage of all the core
> PostgreSQL features. It is one thing to read extensive documentation,
> but it is much more intuitive for me to see an example database, that
> demonstrates the whole thing in
That works perfectly, of course.
Thanks a million!
Terry Fielder
Manager Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
[EMAIL PROTECTED]
Fax: (416) 441-9085
> -Original Message-
> From: Roger Hand [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 19, 2003 1:
On Thu, 2003-08-21 at 14:30, Manfred Koizar wrote:
> On Thu, 21 Aug 2003 15:05:52 +0200, I wrote:
> >>Just wondering, what other databases has transactable DDLs?
> >
> >Firebird.
Rdb/VMS, but your pockets had better be deep...
--
-
> We accidentally created a table called user in our public schema. We
> are now trying to remove the table using DROP TABLE user and even DROP
> TABLE public.user. However every time we try we get an error message:
> ERROR: parser: parse error at or near "user" at character 12
>
> Any suggesti
"Patrick Hatcher" <[EMAIL PROTECTED]> writes:
> We accidentally created a table called user in our public schema. We are
> now trying to remove the table using DROP TABLE user and even DROP TABLE
> public.user. However every time we try we get an error message: ERROR:
> parser: parse error at o
We accidentally created a table called user in our public schema. We are
now trying to remove the table using DROP TABLE user and even DROP TABLE
public.user. However every time we try we get an error message: ERROR:
parser: parse error at or near "user" at character 12
Any suggestion on how to
Manfred Koizar wrote:
On Thu, 21 Aug 2003 21:10:34 +0530, "Shridhar Daithankar"
<[EMAIL PROTECTED]> wrote:
Point I am trying to make is to tune FSM and autovacuum frequency
such that you catch all the dead tuples in RAM
You might be able to catch the pages with dead tuples in RAM, but
currently th
On Thu, 21 Aug 2003 21:10:34 +0530, "Shridhar Daithankar"
<[EMAIL PROTECTED]> wrote:
>Point I am trying to make is to tune FSM and autovacuum frequency
>such that you catch all the dead tuples in RAM
You might be able to catch the pages with dead tuples in RAM, but
currently there's no way to kee
What I am pointing out is that this is all the same issue, and that
solutions to the "we can't do priorities because of locking issues" have
existed for many years. I/O is the same as processors, it is a resource
that needs managing. So the intelligence can be made to exist, it just
needs to be mad
On Thu, Aug 21, 2003 at 09:10:34PM +0530, Shridhar Daithankar wrote:
> Well, nothing can help if the database has dead tuples already.
> Sometime somebody has to take time to run vacuum full and/or
> database reload to get a clean state.
But if you have a busy system, you'll have new dead tuples.
On Thu, Aug 21, 2003 at 12:05:28PM -0400, Edmund Dengler wrote:
> Well, if they are locked waiting on vacuum, then vacuum should upgrade
> it's priority to the highest waiting process (priority inheritance).
> This way, vacuum will be running at a priority level equivalent to who is
> waiting on it
On Thu, 21 Aug 2003, Egor Shipovalov wrote:
> I have a lot of tables of the same structure that represent weekly states of
> a certain system. I'd like to write a function that would take field name,
> number of weeks and return history of that field values as a single row. I
> imagine something
I have a lot of tables of the same structure that represent weekly states of
a certain system. I'd like to write a function that would take field name,
number of weeks and return history of that field values as a single row. I
imagine something like this:
SELECT * FROM history('temperature', 10);
--
Petre Daniel,System & Network Administrator.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Mr. Lane,
I've been taking a look at documentation about timezones (Appendix A/Time
Zone Abbreviations) and it seems that BRT is really missing in that list.
Isn't Brazil important/big enough to have at least BRT and BRST timezones
supported from PostgreSQL? IMHO maybe it's time for a more robus
I'm looking for
a SELECT that I could add a WHERE clause to and get all the CREATE (and
seperately, DROP) statements that I need to rebuild dependent objects before I
make changes to my tables.
For instance, I have
a column datatype I want to change in a table. In order to do this I need
I take it, following this thread, is that REPLACE is not in the SQL
standard?
Bruno Wolff III wrote:
On Thu, Aug 21, 2003 at 12:56:18 -0400,
Edmund Dengler <[EMAIL PROTECTED]> wrote:
Wasn't there a feature in some SQL database which was the equivalent of
UPDATE OR INSERT ... based on the pri
On Thu, Aug 21, 2003 at 12:56:18 -0400,
Edmund Dengler <[EMAIL PROTECTED]> wrote:
> Wasn't there a feature in some SQL database which was the equivalent of
> UPDATE OR INSERT ... based on the primary key? Would this accomplish what
> you want (I know that I have a desire for this feature a couple
Wasn't there a feature in some SQL database which was the equivalent of
UPDATE OR INSERT ... based on the primary key? Would this accomplish what
you want (I know that I have a desire for this feature a couple of times,
as I simply have code or triggers to essentially do the equivalent)? Is
this a
Well, if they are locked waiting on vacuum, then vacuum should upgrade
it's priority to the highest waiting process (priority inheritance).
This way, vacuum will be running at a priority level equivalent to who is
waiting on it.
Regards,
Ed
On Thu, 21 Aug 2003, Andrew Sullivan wrote:
> On Wed, A
On 21 Aug 2003 at 11:26, Andrew Sullivan wrote:
> On Thu, Aug 21, 2003 at 08:38:14PM +0530, Shridhar Daithankar wrote:
> > If a database is clean i.e. no dead tuple, an autovacuum daemon with 1 min
> > interval can achieve pretty much same result, isn't it?
>
> But we're talking about the case o
On Thu, 21 Aug 2003 06:53:42 -0400
rovero <[EMAIL PROTECTED]> wrote:
> expect wrote:
>
> >
> > I don't know a lot about TPC but I understand it's meant to mimic
> > multiple teller xactions and that's what you did. This is not a
> > request mind you but it would be interesting to see how changi
On Thu, Aug 21, 2003 at 08:38:14PM +0530, Shridhar Daithankar wrote:
> If a database is clean i.e. no dead tuple, an autovacuum daemon with 1 min
> interval can achieve pretty much same result, isn't it?
But we're talking about the case of large, busy databases that have
already choked their disk
On Thu, 21 Aug 2003 12:55:35 +0530
Shridhar Daithankar <[EMAIL PROTECTED]> wrote:
> On Wednesday 20 August 2003 22:43, rovero wrote:
> > expect wrote:
> > > Where does pgbench come from?
> >
> > pgbench is one of the modules in the postgresql
> > contrib directory. After building postgresql,
> >
On Wed, 20 Aug 2003 19:50:52 -0700
Joe Conway <[EMAIL PROTECTED]> wrote:
> expect wrote:
> > On Wed, 20 Aug 2003 20:48:34 --0500
> > <[EMAIL PROTECTED]> wrote:
> >
> > Wouldn't the possibility for this kind of humiliation be enough for
> > people to change email clients? Geez. Mozilla has a imp
On 21 Aug 2003 at 11:01, Andrew Sullivan wrote:
> On Thu, Aug 21, 2003 at 03:40:29PM +1000, Martijn van Oosterhout wrote:
> > Given lazy vacuum doesn't hold locks for long periods, it could be
> > an idea to continuously spend 1% of your disk bandwidth on a
> > background vacuum. As for vacuum ful
On Wed, Aug 20, 2003 at 05:30:14PM -0400, Joseph Tate wrote:
> Is there a way to get a list of all the currently open transactions on a
> database?
You can use the statistics in pg_stat_activity if you have the query
stats turned on.
A
--
Andrew Sullivan 204-4141
On 21 Aug 2003 at 10:59, Andrew Sullivan wrote:
> On Wed, Aug 20, 2003 at 05:58:32PM -0400, Tom Lane wrote:
> > Jan Wieck <[EMAIL PROTECTED]> writes:
> > > the LRU chain but rather at it's end? This way a vacuum on a large table
> > > will not cause a complete cache eviction.
> >
> > I think wha
On Wed, Aug 20, 2003 at 11:41:41PM +0200, Karsten Hilbert wrote:
> You mean, like, "nice 19" or so ?
ISTR someone reporting problems with locking on the performance list
from doing exactly that. The problem is that the vacuum back end
might take a lock and then not get any processor time -- in wh
On Thu, Aug 21, 2003 at 03:40:29PM +1000, Martijn van Oosterhout wrote:
> Given lazy vacuum doesn't hold locks for long periods, it could be
> an idea to continuously spend 1% of your disk bandwidth on a
> background vacuum. As for vacuum full, I don't know if you could do
> the same thing.
Assumi
On Wed, Aug 20, 2003 at 05:58:32PM -0400, Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > the LRU chain but rather at it's end? This way a vacuum on a large table
> > will not cause a complete cache eviction.
>
> I think what we really need is a way to schedule VACUUM's I/O at a lower
"Vilson farias" <[EMAIL PROTECTED]> writes:
> PostgreSQL 7.3.4
> bxs=# SELECT timeofday();
> timeofday
> -
> Thu Aug 21 10:04:18.215420 2003 BRT
> (1 row)
> bxs=# SELECT CAST(timeofday() AS timestamp);
> ERROR: Bad timestamp external r
Jeff Davis <[EMAIL PROTECTED]> writes:
> I had an idea about using aggregates: what if I made an aggregate function
> called "first" that just returned the value in the first tuple it
> encountered?
You could make that work in 7.4, but not in any existing releases.
The trouble is that you need
33 matches
Mail list logo
