Marc G. Fournier wrote:
Yeah, sure wish we could generate those man pages automatically :-(
Is there a reason why we can't?
Usually, you need to look them over and fix them up a bit. You also
need a patched version of the processing tools.
--
Peter Eisentraut
Greets,
While I was finishing up SRF support in PL/Py, I noticed that when VPC is the
selected mode for a table function, ExecMakeTableFunctionResult will set
rsinfo.isDone to ExprSingleResult each time it loops to fetch another value
(when a direct_function_call). This makes the VPC-SRF author
Tom Lane wrote:
I haven't seen any particular reason why we should adopt another SCM.
Perhaps BitKeeper or SubVersion would be better for our purposes than
CVS, but are they enough better to justify the switchover costs?
BitKeeper ist not open source, so it's out of the question for most
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Scott Marlowe
Sent: 09 August 2004 06:31
To: PostgreSQL-development
Subject: [HACKERS] Windows binary in the beta directory?
Since this is the first release supporting Windows natively,
and
Tom Lane wrote:
(a) And there would be untrusted code running as postgres exactly
why?
Because someone has cracked the PostgreSQL server.
(b) Seems to me the real security bug here is the mere existence of
that ioctl call.
Probably. I'm just pointing out the findings about the environment
Hi guys,
Is it safe to update the atttypid of a timestamp column to be a
timestamptz column? I wish to do this on a production database, so I
need to be sure!
Thanks,
Chris
---(end of broadcast)---
TIP 2: you can get off all lists at once with
Is it safe to update the atttypid of a timestamp column to be a
timestamptz column? I wish to do this on a production database, so I
need to be sure!
Oh, and what about indexes on them? Do I just drop them beforehand and
recreate?
Chris
---(end of
I read this in the release notes:
---
# Database-wide ANALYZE does not hold locks across tables (Tom)
This reduces the potential for deadlocks against other backends that
want exclusive locks on tables. To get the benefit of this change, do
not execute database-wide ANALYZE inside a transaction
I'm testing PITR using pgbench and postgresql ver.8.0bata.
I think that result of recovery is wrong. My test procedure
is as follows:
I edited postgresql.conf for PITR and started the postmaster.
And I executed pgbench -t 2.
% pgbench -t 2
I did backup procedure
Peter Eisentraut wrote:
Tom Lane wrote:
I haven't seen any particular reason why we should adopt another SCM.
Perhaps BitKeeper or SubVersion would be better for our purposes than
CVS, but are they enough better to justify the switchover costs?
BitKeeper ist not open source, so it's out of the
In article [EMAIL PROTECTED],
Tom Lane [EMAIL PROTECTED] writes:
Robert Treat [EMAIL PROTECTED] writes:
Well, as yall have pointed out, the feature is not sql spec (for some
reason I thought it had been put in) so since the update syntax seems
quite similar to oracles, perhaps they can
Hi all,
I have seen the big debat about to have the delay
off or on by default.
Why not enable it by default and introduce a new
parameter to vacuum command itself ? Something like:
VACUUM WITH DELAY 100;
this will permit to change easilly the delay in the maintainance
scripts.
Regards
Hi,
On Monday 09 August 2004 09:30, you wrote:
Tom Lane wrote:
I haven't seen any particular reason why we should adopt another SCM.
Perhaps BitKeeper or SubVersion would be better for our purposes than
CVS, but are they enough better to justify the switchover costs?
BitKeeper ist not
On Mon, 2004-08-09 at 05:19, Gaetano Mendola wrote:
Hi all,
I have seen the big debat about to have the delay
off or on by default.
Why not enable it by default and introduce a new
parameter to vacuum command itself ? Something like:
VACUUM WITH DELAY 100;
this will permit to
On Mon, Aug 09, 2004 at 04:44:58PM +0800, Christopher Kings-Lynne wrote:
I read this in the release notes:
---
# Database-wide ANALYZE does not hold locks across tables (Tom)
This reduces the potential for deadlocks against other backends that
want exclusive locks on tables. To get the
Peter Eisentraut [EMAIL PROTECTED] writes:
Marc G. Fournier wrote:
Yeah, sure wish we could generate those man pages automatically :-(
Is there a reason why we can't?
Usually, you need to look them over and fix them up a bit. You also
need a patched version of the processing tools.
James William Pye [EMAIL PROTECTED] writes:
While I was finishing up SRF support in PL/Py, I noticed that when VPC is the
selected mode for a table function, ExecMakeTableFunctionResult will set
rsinfo.isDone to ExprSingleResult each time it loops to fetch another value
(when a
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Is it safe to update the atttypid of a timestamp column to be a
timestamptz column?
For sufficiently small values of safe, sure.
The problem is that unless you live in GMT zone, the interpretation
of values is different: the zero reference for
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
I read this in the release notes:
---
# Database-wide ANALYZE does not hold locks across tables (Tom)
This reduces the potential for deadlocks against other backends that
want exclusive locks on tables. To get the benefit of this change, do
On 8/9/2004 12:29 AM, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
Well, as yall have pointed out, the feature is not sql spec (for some
reason I thought it had been put in) so since the update syntax seems
quite similar to oracles, perhaps they can provide a pointer on delete
syntax as
Harald Fuchs [EMAIL PROTECTED] writes:
Actually, MySQL supports two different syntaxes for multi-table DELETEs:
1. DELETE t1,t2 FROM t1,t2,t3 WHERE t1.id=t2.id AND t2.id=t3.id;
(introduced in MySQL 4.0.0)
2. DELETE FROM t1,t2 USING t1,t2,t3 WHERE t1.id=t2.id AND t2.id=t3.id;
Alvaro Herrera Munoz [EMAIL PROTECTED] writes:
I think both VACUUM and ANALYZE could be best served by appropiate use
of short-lived ResourceOwners. It needs some thought though.
At least for VACUUM FULL, this is pretty much a nonstarter: it needs a
real live genuine COMMIT in the middle. No
On 8/9/2004 7:19 AM, Gaetano Mendola wrote:
Hi all,
I have seen the big debat about to have the delay
off or on by default.
Why not enable it by default and introduce a new
parameter to vacuum command itself ? Something like:
VACUUM WITH DELAY 100;
It's not just one parameter to tune here. It
Worked through some troubles on irc last night, thought I would post it in
case anyone else sees something similar.
system is Slackware 8.1, Linux phppgadmin 2.4.18 #2 Fri May 31 01:21:23 PDT
2002 i586 unknown
./configure was run with '--prefix=/usr/local/pgsql-8.0.0' '--enable-debug'
On Monday 09 Aug 2004 9:18 pm, Robert Treat wrote:
but I was pretty sure I had lpthread library on my machine (and verified
this with some help from irc). however Makefile.global told me
PTHREAD_CFLAGS = -pthread -D_REENTRANT -D_THREAD_SAFE
-D_POSIX_PTHREAD_SEMANTICS
PTHREAD_LIBS
People,
DELETE FROM target_tbl USING other_tbls WHERE ...
Feels much more understandable. The second FROM looks like a hickup.
Yes, although imagine:
DELETE FROM staff USING users JOIN logons USING (user_id)
WHERE last_logon ( now() - '6 months');
Not as bad as FROM, but still a bit
KL,
Is it safe to update the atttypid of a timestamp column to be a
timestamptz column? I wish to do this on a production database, so I
need to be sure!
I wouldn't try this without running it against a test database copy first.
I've already discovered that a backend change to a column
Jan Wieck [EMAIL PROTECTED] writes:
What about
DELETE FROM staff JOIN users ...
then?
I don't much care for that, mainly because in my mind x JOIN y should
always be semantically equivalent to y JOIN x. I think we want a real
clear syntactical separation between the deletion target table and
On 8/8/2004 11:58 AM, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
The only open issue I see for beta1 is perhaps disabling vacuum delay.
Given that Jan is clearly in the minority on that, I suggest we just
turn it off for beta1. We can always turn it on later if he manages
to
Folks,
Per our discussion earlier this year, I really think that we could shorten the
beta process and make it more effective if someone can step forward to be the
8.0 Beta Leader. This person would have to:
1) track platform tests, namely which platforms have been tested, what they
Josh Berkus [EMAIL PROTECTED] writes:
Oh, and MySQL's multi-table deletes: PLEASE tell me that's not
SQL-standard.
It's not.
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to
OKADA Satoshi [EMAIL PROTECTED] writes:
I'm testing PITR using pgbench and postgresql ver.8.0bata.
Is this actually the official beta1 version, or is it a snapshot from
last week sometime? In the first commit that had pg_start_backup(),
there wasn't any logic to ensure that the recovery replay
Hi!
I'm currently working on the psql tab-complete code, fixing quite a lot
of bugs/annoyances in the process.
One of the things I'm trying to do is syncing the available commands in
psql with the docs - during this work I found two irritating things
regarding tablespaces:
1. there is no
Seems reasonable to me. A SRF function really ought to explicitly set
isDone on every call anyway.
Aye, it seems reasonable, but a bit inconsistent with the effect of
ExecMakeFunctionResult, which does the same thing but bases the continuity of
the result gathering on the isDone pointer, which
Jan Wieck wrote:
On 8/9/2004 7:19 AM, Gaetano Mendola wrote:
Hi all,
I have seen the big debat about to have the delay
off or on by default.
Why not enable it by default and introduce a new
parameter to vacuum command itself ? Something like:
VACUUM WITH DELAY 100;
It's not just one
On 08/09/04:32/1, Peter Eisentraut wrote:
BitKeeper ist not open source, so it's out of the question for most
people. Subversion is shockingly unstable. I'm very open for
something that replaces CVS, but I'd rather not use any than one of
these two.
From my casual usage of svn, I haven't
On 8/9/2004 12:53 PM, Josh Berkus wrote:
People,
DELETE FROM target_tbl USING other_tbls WHERE ...
Feels much more understandable. The second FROM looks like a hickup.
Yes, although imagine:
DELETE FROM staff USING users JOIN logons USING (user_id)
WHERE last_logon ( now() - '6 months');
Josh Berkus wrote:
Per our discussion earlier this year, I really think that we could
shorten the beta process and make it more effective if someone can
step forward to be the 8.0 Beta Leader. This person would have
to:
1) track platform tests, namely which platforms have been tested,
what
I did a little test on the various options of fsync.
I'm not sure my tests are scientific enough for general publication or
evaluation, all I am doing is performaing a loop that inserts a value into
a table 1 million times.
create table testndx (value integer, name varchar);
create index
I did a little test on the various options of fsync.
I'm not sure my tests are scientific enough for general publication or
evaluation, all I am doing is performaing a loop that inserts a value into
a table 1 million times.
create table testndx (value integer, name varchar);
create index
On Mon, Aug 09, 2004 at 07:19:44PM +0200, Gaetano Mendola wrote:
So the other parameter will inserted in the new sintax too, I think is
fundamental
the ability of override this values during the vacuum call:
VACUUM WITH DELAY 100 [ ];
What's wrong with
SET vacuum_delat 100;
SET
On Mon, 2004-08-09 at 13:57, Peter Eisentraut wrote:
Josh Berkus wrote:
Per our discussion earlier this year, I really think that we could
shorten the beta process and make it more effective if someone can
step forward to be the 8.0 Beta Leader. This person would have
to:
1) track
On Mon, 9 Aug 2004, Josh Berkus wrote:
Folks,
Per our discussion earlier this year, I really think that we could shorten the
beta process and make it more effective if someone can step forward to be the
8.0 Beta Leader. This person would have to:
1) track platform tests, namely which platforms
Marc,
Is there a reason why Bruce isn't doing it like he has for all previous
releases? As he previously held such a role, shouldn't it be he calling
for someone to take over that role from him?
Clearly I was confused about the import of a discussion we had on Core, some 3
months ago or
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alvaro Herrera wrote:
| On Mon, Aug 09, 2004 at 07:19:44PM +0200, Gaetano Mendola wrote:
|
|
|So the other parameter will inserted in the new sintax too, I think is
|fundamental
|the ability of override this values during the vacuum call:
|
|VACUUM
Andreas Pflug wrote:
Tom Lane wrote:
Do we have a TODO for allowing users to
force switching to a new WAL file segment?
Together with PITR, this might make sense?
Another idea:
Has anyone tried to put the WAL segment directory on a cluster
filesystem and use that for cold (perhaps even hot)
On 8/9/2004 1:19 PM, Gaetano Mendola wrote:
Jan Wieck wrote:
On 8/9/2004 7:19 AM, Gaetano Mendola wrote:
Hi all,
I have seen the big debat about to have the delay
off or on by default.
Why not enable it by default and introduce a new
parameter to vacuum command itself ? Something like:
VACUUM
Jan Wieck wrote:
On 8/8/2004 11:58 AM, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
The only open issue I see for beta1 is perhaps disabling vacuum delay.
Given that Jan is clearly in the minority on that, I suggest we just
turn it off for beta1. We can always turn it on
Hi everybody,
I never meant my emails to be spam. That's why i am just asking whether my
questions here are out of subject. Typically my questions are about
postgresql source code, like the question below. Please advise me whether
i should forward my questions to somewhere else.
Thanks a lot,
--h
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
1. there is no COMMENT ON TABLESPACE support
That's right.
2. how is one supposed to move indexes(not tables) to another tablespace?
Use ALTER TABLE on the index.
regards, tom lane
---(end of
[EMAIL PROTECTED] writes:
I did a little test on the various options of fsync.
There were considerably more extensive tests back when we created the
different WAL options, and the conclusions seemed to be that the best
choice is platform-dependent and also usage-dependent. (In particular,
it
Tom Lane wrote:
Would it be possible to automatically generate an un-fixed-up version
for beta releases? I'd rather have the right info in an ugly format
than the wrong info ...
In doc/src/, run make man.tar.gz. The required software should be
listed in the documentation. I don't actually
On Mon, 9 Aug 2004, Peter Eisentraut wrote:
Tom Lane wrote:
Would it be possible to automatically generate an un-fixed-up version
for beta releases? I'd rather have the right info in an ugly format
than the wrong info ...
In doc/src/, run make man.tar.gz. The required software should be
listed
[EMAIL PROTECTED] writes:
I did a little test on the various options of fsync.
There were considerably more extensive tests back when we created the
different WAL options, and the conclusions seemed to be that the best
choice is platform-dependent and also usage-dependent. (In particular,
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
1. there is no COMMENT ON TABLESPACE support
That's right.
2. how is one supposed to move indexes(not tables) to another tablespace?
Use ALTER TABLE on the index.
Hmm...not ALTER INDEX? Now that there's an operation that
Marc G. Fournier wrote:
On Mon, 9 Aug 2004, Josh Berkus wrote:
Folks,
Per our discussion earlier this year, I really think that we could shorten the
beta process and make it more effective if someone can step forward to be the
8.0 Beta Leader. This person would have to:
1) track
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
1. there is no COMMENT ON TABLESPACE support
That's right.
Added to TODO:
* Add COMMENT for tablespaces
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610)
[EMAIL PROTECTED] wrote:
Furthermore, it seems to also have the added benefit of reducing the I/O
storm at checkpoints over a system running with fsync off.
I'm really serious about this, changing this one parameter had dramatic
results on performance. We should have a general call to users
On Mon, 9 Aug 2004, Bruce Momjian wrote:
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
1. there is no COMMENT ON TABLESPACE support
That's right.
Added to TODO:
* Add COMMENT for tablespaces
Well, Chris did bring this up but it will have the same problem as
Gavin Sherry wrote:
On Mon, 9 Aug 2004, Bruce Momjian wrote:
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
1. there is no COMMENT ON TABLESPACE support
That's right.
Added to TODO:
* Add COMMENT for tablespaces
Well, Chris did bring this up but it
On 8/9/2004 3:46 PM, Bruce Momjian wrote:
Jan Wieck wrote:
On 8/8/2004 11:58 AM, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
The only open issue I see for beta1 is perhaps disabling vacuum delay.
Given that Jan is clearly in the minority on that, I suggest we just
turn it off
On Thursday 05 August 2004 04:43 pm, Hicham G. Elmongui wrote:
In join_selectivity function (plancat.c), a function call is made to
OidFunctionCall4 (fmgr.c), which in turn calls a function pointer.
In need to know what is the actual function being called from
OidFunctionCall4 if the
Maybe this should be brought up-to-date slightly?
http://developer.postgresql.org/beta.php
Or maybe point elsewhere at least where the more up-to-date info actually
is.
--
Serguei A. Mokhov| /~\The ASCII
Computer Science Department | \ / Ribbon Campaign
Concordia University
Hello Peter,
backend/po/fr.po had 99% translations done for 7.4, and nos it is totally
missing for the current CVS tip (it is in the Attic)... why? Most
of those messasge are still applicable to the current, no? Commit message
from you from 2 weeks ago says:
2 weeks petere
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jan Wieck wrote:
| On 8/9/2004 1:19 PM, Gaetano Mendola wrote:
|
| Jan Wieck wrote:
|
| On 8/9/2004 7:19 AM, Gaetano Mendola wrote:
|
| Hi all,
| I have seen the big debat about to have the delay
| off or on by default.
|
| Why not enable it by default
This is the kind of thing I can usually help with.
However, right now I'm a little swamped with customer work.
I can back someone up, though.
--elein
On Mon, Aug 09, 2004 at 06:28:33PM -0400, Bruce Momjian wrote:
Marc G. Fournier wrote:
On Mon, 9 Aug 2004, Josh Berkus wrote:
Folks,
On Mon, Aug 09, 2004 at 06:47:45PM -0400, Bruce Momjian wrote:
Gavin Sherry wrote:
Well, Chris did bring this up but it will have the same problem as other
shared tables, from memory. That is, you can add the comment in one
database, but wont see if from another.
Oh, that shared thing!
I'll be modifying that tonight ...
On Mon, 9 Aug 2004, Serguei A. Mokhov wrote:
Maybe this should be brought up-to-date slightly?
http://developer.postgresql.org/beta.php
Or maybe point elsewhere at least where the more up-to-date info actually
is.
--
Serguei A. Mokhov| /~\The
On Sat, 07 Aug 2004 10:24:34 -0400, Jan Wieck [EMAIL PROTECTED]
wrote:
I have not heard of updatable subselects yet.
http://asktom.oracle.com/pls/ask/f?p=4950:8:6693556430011788783::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:273215737113,
| Here we update a join. [...]
| [EMAIL PROTECTED] update
|
Bruce Momjian [EMAIL PROTECTED] writes:
Added to TODO:
* Add COMMENT for tablespaces
Oh, that shared thing! OK, removed.
Well, it's a legitimate thing to have in TODO, just as long as you don't
think it's trivial ;-). But don't we already have a TODO item about
properly supporting
Just out of interest, what happens to the difference if you use *ext3*
(perhaps with data=writeback)
regards
Mark
[EMAIL PROTECTED] wrote:
I did a little test on the various options of fsync.
...
create table testndx (value integer, name varchar);
create index testndx_val on testndx (value);
Kevin Brown [EMAIL PROTECTED] writes:
Tom Lane wrote:
Use ALTER TABLE on the index.
Hmm...not ALTER INDEX? Now that there's an operation that actually
modifies an index instead of the table itself, should there be an ALTER
INDEX? It would be cleaner and more consistent, IMO...
[ shrug ]
Updated ...
On Mon, 9 Aug 2004, Marc G. Fournier wrote:
I'll be modifying that tonight ...
On Mon, 9 Aug 2004, Serguei A. Mokhov wrote:
Maybe this should be brought up-to-date slightly?
http://developer.postgresql.org/beta.php
Or maybe point elsewhere at least where the more up-to-date info
Let me be one of the first to say thank you to all of you guys for yet
another awesome version of PgSQL, beta or not. My company and I
appreciate all the hard work and such that has gone into making this
version happen. Keep up the good work and let me know where I can help.
Sincerely,
Gavin
I wouldn't try this without running it against a test database copy first.
I've already discovered that a backend change to a column data type like your
describing can disrupt indexes, views, and analyze rows based on the table --
the last time I did such, I ended up having to dump and reload
Hmm...not ALTER INDEX? Now that there's an operation that actually
modifies an index instead of the table itself, should there be an ALTER
INDEX? It would be cleaner and more consistent, IMO...
Errr, unlike all the other uses for alter table and friends? ie:
OWNER TO
RENAME TO
SET TABLESPACE
1. there is no COMMENT ON TABLESPACE support
That's right.
That's deliberate.
Added to TODO:
* Add COMMENT for tablespaces
You may as well make that:
* Add COMMENT ON for all cluster global objects (users, groups,
databases and tablespaces)
Chris
---(end of
Tom Lane wrote:
OKADA Satoshi [EMAIL PROTECTED] writes:
I'm testing PITR using pgbench and postgresql ver.8.0bata.
Is this actually the official beta1 version, or is it a snapshot from
last week sometime?
I got it from
ftp.postgresql.org/pub/source/v8.0.0beta/postgresql-8.0.0beta1.tar.gz,
OK, added.
---
Christopher Kings-Lynne wrote:
1. there is no COMMENT ON TABLESPACE support
That's right.
That's deliberate.
Added to TODO:
* Add COMMENT for tablespaces
You may as well make that:
*
OKADA Satoshi [EMAIL PROTECTED] writes:
Tom Lane wrote:
Is this actually the official beta1 version, or is it a snapshot from
last week sometime?
I got it from
ftp.postgresql.org/pub/source/v8.0.0beta/postgresql-8.0.0beta1.tar.gz, and
xlog.c revision number is 1.157.
Okay, so
Gaetano Mendola wrote:
However I think is annoying to write:
set vacuum_cost_delay = 100;
vacuum table big_huge;
set vacuum_cost_delay = 0;
set whatelse;
vacuum table night_table;
Well, you are already seting it to zero for night, so why not just set
it to non-zero for day?
Christopher Kings-Lynne wrote:
Hmm...not ALTER INDEX? Now that there's an operation that actually
modifies an index instead of the table itself, should there be an ALTER
INDEX? It would be cleaner and more consistent, IMO...
Errr, unlike all the other uses for alter table and friends? ie:
Errr, unlike all the other uses for alter table and friends? ie:
OWNER TO
Which changes the attributes of the table...
And indexes.
RENAME TO
Same.
And indexes.
SET TABLESPACE
Which again changes the attributes of the table..
And indexes.
Chris
---(end of
Just out of interest, what happens to the difference if you use *ext3*
(perhaps with data=writeback)
Actually, I was working for a client, so it wasn't a general exploritory,
but I can say that early on we discovered that ext3 was about the worst
file system for PostgreSQL. We gave up on it and
[EMAIL PROTECTED] writes:
Just out of interest, what happens to the difference if you use *ext3*
(perhaps with data=writeback)
Actually, I was working for a client, so it wasn't a general exploritory,
but I can say that early on we discovered that ext3 was about the worst
file system for
On 8/9/2004 7:41 PM, Gaetano Mendola wrote:
If I remember well this is the first command that need to change
GUC in order to change behaviour, I don't think we wrote:
set vacuum_mode = full;
set vacuum_verbosity = on;
vacuum;
You got a point here. However, we don't have
SELECT foo FROM bar
Okay, so theoretically it should work ... I'm trying it now to see
if I can reproduce the problem locally.
It took several tries, but eventually I did reproduce it. It seems
the triggering condition is for the REDO pointer to be before the
checkpoint record itself. Not sure why, yet, but it
On Monday 09 August 2004 13:15, Josh Berkus wrote:
1) track platform tests, namely which platforms have been tested, what they
reported, and which have not, including soliciting on the lists for more
platform testers;
I wonder, would folks be interested in keeping a supported programs list as
Hi,
I'm looking to find all records in pg_depend that show that some columns
in my db depend on the 'timestamp' type. So I do this:
select * from pg_depend where refclassid=1247 and refobjid=1114;
1257 is the oid of the pg_type table and 1114 is the oid of the
timestamp type.
It returns just
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
How is that possible? I have heaps of columns that use the timestamp type:
We don't make dependency entries for pinned objects (which includes all
built-in datatypes).
regards, tom lane
---(end
Tom Lane wrote:
[EMAIL PROTECTED] writes:
The improvements were REALLY astounding, and I would like to know if other
Linux users see this performance increase, I mean, it is almost 8~10 times
faster than using fsync.
Furthermore, it seems to also have the added benefit of reducing the I/O
storm
91 matches
Mail list logo
