On Thu, 2005-08-04 at 10:56 +0800, Qingqing Zhou wrote:
Tom Lane [EMAIL PROTECTED] writes
Since there is no xlog replay mechanism to CREATE INDEX (bottom-up
method),
so CREATE INDEX won't get replayed in PITR?
On what do you base either part of that statement?
I have learnt that Tom
On Tue, 2005-08-02 at 14:22 -0700, Mark Wong wrote:
I've started scaling dbt3 up to the 10GB scale factor against CVS and
the fast COPY patch:
http://www.testing.osdl.org/projects/dbt3testing/results/dev4-010/53/
Try www1 if this URL fails for you.
I'm sure there are some better database
Simon Riggs [EMAIL PROTECTED] writes
I have learnt that Tom means: read the code. :-)
CREATE INDEX doesn't produce xlog records *except* when you use PITR, so
PITR does work correctly.
wstate.btws_use_wal = XLogArchivingActive() !wstate.index-rd_istemp;
Ah-oh, that's true ;-)
Wow! a lot of people seem to want it!
I am dumping out with pg_dump right now, it may take a few hours.
It is in PostgreSQL 8.0.3
Does anyone have access to a high bandwidth server? I could mail it on a
DVD to someone who would host it.
David Fetter wrote:
On Wed, Aug 03, 2005 at 05:00:16PM
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
I don't like this approach to solving the problem. I would rather see
the check modified to allow the ownership change provided:
the user issueing the command has access to destination role
AND
(
the
I was reminded again today of the problem that once a database has been
in existence long enough for the OID counter to wrap around, people will
get occasional errors due to OID collisions, eg
http://archives.postgresql.org/pgsql-general/2005-08/msg00172.php
Getting rid of OID usage in user
* Mark Woodward ([EMAIL PROTECTED]) wrote:
I just finished converting and loading the US census data into PostgreSQL
would anyone be interested in it for testing purposes?
It's a *LOT* of data (about 40+ Gig in PostgreSQL)
How big dumped compressed? I may be able to host it depending on
* Mark Woodward ([EMAIL PROTECTED]) wrote:
I just finished converting and loading the US census data into
PostgreSQL
would anyone be interested in it for testing purposes?
It's a *LOT* of data (about 40+ Gig in PostgreSQL)
How big dumped compressed? I may be able to host it depending on
* Mark Woodward ([EMAIL PROTECTED]) wrote:
How big dumped compressed? I may be able to host it depending on how
big it ends up being...
It's been running for about an hour now, and it is up to 3.3G.
Not too bad. I had 2003 (iirc) loaded into 7.4 at one point.
pg_dump tiger | gzip
Am Donnerstag, den 04.08.2005, 08:40 -0400 schrieb Mark Woodward:
* Mark Woodward ([EMAIL PROTECTED]) wrote:
I just finished converting and loading the US census data into
PostgreSQL
would anyone be interested in it for testing purposes?
It's a *LOT* of data (about 40+ Gig in
* Mark Woodward ([EMAIL PROTECTED]) wrote:
How big dumped compressed? I may be able to host it depending on
how
big it ends up being...
It's been running for about an hour now, and it is up to 3.3G.
Not too bad. I had 2003 (iirc) loaded into 7.4 at one point.
Cool.
pg_dump tiger |
Stephen Frost [EMAIL PROTECTED] writes:
Does it really? I don't think so. If you have owner privileges on the
schema you can grant create rights to the role, then either ALTER OWNER
if the patch is kept or just change to the role, create table x as
select * from y;, etc, and then revoke the
It's been running for about an hour now, and it is up to 3.3G.
pg_dump tiger | gzip tiger.pgz
| bzip2 tiger.sql.bz2 :)
I find bzip2 FAR SLOWER than the gain in compression.
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
It's been running for about an hour now, and it is up to 3.3G.
pg_dump tiger | gzip tiger.pgz
| bzip2 tiger.sql.bz2 :)
Chris
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Mark Woodward [EMAIL PROTECTED] writes:
Why is there collision? It is because the number range of an OID is
currently smaller than the possible usage.
Expanding OIDs to 64 bits is not really an attractive answer, on several
grounds:
1. Disk space.
2. Performance. Doing this would require
I haven't seen this option, and does anyone thing it is a good idea?
A option to pg_dump and maybe pg_dump all, that dumps only the table
declarations and the data. No owners, tablespace, nothing.
This, I think, would allow more generic PostgreSQL data transfers.
---(end
Mark Woodward [EMAIL PROTECTED] writes:
Why is there collision? It is because the number range of an OID is
currently smaller than the possible usage.
Expanding OIDs to 64 bits is not really an attractive answer, on several
grounds:
1. Disk space.
I don't really see this as a problem
Hi,
I've recently had problems with slow queries caused by the selectivity
of the @ ltree operator, as you may see in my post here:
http://archives.postgresql.org/pgsql-performance/2005-07/msg00473.php
Someone on IRC (AndrewSN if I'm not wrong) pointed out that the
restriction selectivity
Mark Woodward [EMAIL PROTECTED] writes:
2. Performance. Doing this would require widening Datum to 64 bits,
which is a system-wide performance hit on 32-bit machines.
Do you really think it would make a measurable difference, more so than
your proposed solution? (I'm skeptical it would be
Mark Woodward [EMAIL PROTECTED] writes:
2. Performance. Doing this would require widening Datum to 64 bits,
which is a system-wide performance hit on 32-bit machines.
Do you really think it would make a measurable difference, more so than
your proposed solution? (I'm skeptical it would be
It is 4.4G in space in a gzip package.
I'll mail a DVD to two people who promise to host it for Hackers.
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Am Donnerstag, den 04.08.2005, 10:26 -0400 schrieb Mark Woodward:
I haven't seen this option, and does anyone thing it is a good idea?
A option to pg_dump and maybe pg_dump all, that dumps only the table
declarations and the data. No owners, tablespace, nothing.
This, I think, would allow
Am Donnerstag, den 04.08.2005, 10:26 -0400 schrieb Mark Woodward:
I haven't seen this option, and does anyone thing it is a good idea?
A option to pg_dump and maybe pg_dump all, that dumps only the table
declarations and the data. No owners, tablespace, nothing.
This, I think, would allow
Matteo Beccati [EMAIL PROTECTED] writes:
Someone on IRC (AndrewSN if I'm not wrong) pointed out that the
restriction selectivity function for @ is contsel, which returns a
constant value of 0.001. So I started digging in the source code trying
to understand how the default behaviour could
If you haven't visited the buildfarm recently you might have missed a
few developments:
. we are now reporting flags used on builds on the main dashboard page -
I am working on making that look nicer by using icons - see
http://www.pgbuildfarm.org/cgi-bin/show_status4.pl for prgress.
.
Am Donnerstag, den 04.08.2005, 11:52 -0400 schrieb Mark Woodward:
Am Donnerstag, den 04.08.2005, 10:26 -0400 schrieb Mark Woodward:
I haven't seen this option, and does anyone thing it is a good idea?
A option to pg_dump and maybe pg_dump all, that dumps only the table
declarations and
Matteo Beccati [EMAIL PROTECTED] writes:
This also made me think: is there a reason why geometric selectivity
functions return constant values rather than checking statistics for a
better result?
Because no one's ever bothered to work on them. You should talk to
the PostGIS guys, however,
Mark Woodward [EMAIL PROTECTED] writes:
I'm too lazy to run an experiment, but I believe it would. Datum is
involved in almost every function-call API in the backend. In
particular this means that it would affect performance-critical code
paths.
I hear you on the lazy part, but if OID
You can send it to me, and ehpg will host it. I'll send you a
private email with my info.
Gavin
On Aug 4, 2005, at 8:26 AM, Mark Woodward wrote:
It is 4.4G in space in a gzip package.
I'll mail a DVD to two people who promise to host it for Hackers.
---(end of
Mark Woodward [EMAIL PROTECTED] writes:
Actually, there isn't a setting to just dump the able definitions and the
data. When you dump the schema, it includes all the tablespaces,
namespaces, owners, etc.
Just the table nd object declarations and data would be useful.
pg_dump -t table ?
Tom Lane wrote:
After looking at this a little, it doesn't seem like it has much to do
with the ordinary 2-D notion of containment. In most of the core
geometric types, the histogram ordering is based on area, and so
testing the histogram samples against the query doesn't seem like it's
able to
Matteo Beccati [EMAIL PROTECTED] writes:
Moving it in contrib/ltree would be more difficult to me because it
depends on other functions declared in selfuncs.c
(get_restriction_variable, etc).
I'd be willing to consider exporting those functions from selfuncs.c.
Mark Woodward [EMAIL PROTECTED] writes:
I'm too lazy to run an experiment, but I believe it would. Datum is
involved in almost every function-call API in the backend. In
particular this means that it would affect performance-critical code
paths.
I hear you on the lazy part, but if OID
Mark Woodward [EMAIL PROTECTED] writes:
Actually, there isn't a setting to just dump the able definitions and
the
data. When you dump the schema, it includes all the tablespaces,
namespaces, owners, etc.
Just the table nd object declarations and data would be useful.
pg_dump -t table ?
I
On Thu, Aug 04, 2005 at 12:20:24PM -0400, Tom Lane wrote:
Mark Woodward [EMAIL PROTECTED] writes:
I'm too lazy to run an experiment, but I believe it would. Datum is
involved in almost every function-call API in the backend. In
particular this means that it would affect
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
The alternative is to say that plpython isn't supported on BSDen unless
you choose to build an unthreaded libpython.
I'm OK with that, but if that's what's done I think we should check for
it up front at configure
Mark Woodward wrote:
It is 4.4G in space in a gzip package.
I'll mail a DVD to two people who promise to host it for Hackers.
Would it be easier to release the program you did to do
this conversion?
I use this pretty short (274 line) C program:
http://www.forensiclogic.com/tmp/tgr2sql.c
It looks like when we changed regress/GNUmakefile to pull rules from
Makefile.shlib, cygwin got broken in the process.
The problem is that regess.dll ends up being a symlink back to itself,
because we do a:
$(NAME)$(DLSUFFIX): $(shlib)
rm -f $(NAME)$(DLSUFFIX)
$(LN_S) $(shlib)
Rocco Altier [EMAIL PROTECTED] writes:
It looks like when we changed regress/GNUmakefile to pull rules from
Makefile.shlib, cygwin got broken in the process.
...
I don't know enough about the rest of the way the cygwin port is put
together, but it seems that the other platforms all have
On Thu, Aug 04, 2005 at 08:14:51PM +0200, Stefan Kaltenbrunner wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
The alternative is to say that plpython isn't supported on BSDen unless
you choose to build an unthreaded libpython.
I'm OK with that, but if that's
I thought bout it, but it isn't the best program around, but it does work.
My program also reformats numbers, i.e. long/lat become properly
decimal-ed numerics, zips become integers, etc.
The question is...
Do you download the raw data and convert it into a database, or do you
download the
Tom Lane tgl at sss.pgh.pa.us writes:
I was reminded again today of the problem that once a database has been
in existence long enough for the OID counter to wrap around, people will
get occasional errors due to OID collisions, eg
Magnus Hagander [EMAIL PROTECTED] writes
I suggest you try using Process Explorer from www.sysinternals.com to
figure out who has the file open. Most of the time it should be able to
tell you exactly who has locked the file - at least as long as it's done
from userspace. I'm not 100% sure on
Hello
I am working on trunc and round function now. I have some problems with
timestemp with time zone datatype. First question?
is correct behaviour (I am in GMT+2 time zone)?
select current_timestamp, date_trunc('year', current_timestamp),
date_trunc('month', current_timestamp);
Hi!
Can someone with a FreeBSD 6.x installation confirm the build error
referred here:
http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.6.2005073022/postgresql-client-7.3.10.log
I maintain the postgresql ports for FreeBSD, but I have no version 6
installed yet.
Thanks,
Palle
dennis, look at vtiger crm (http://www.vtiger.com)
vtiger is a fork of sugarcrm and are 100% commited to open source.
(unlike sugar, who offer the full version only for purchase)
and they actively want to support more databases.
regards,
/sak
Denis Lussier wrote:
At EnterpriseDB we're doing a
Rocco Altier schrieb:
It looks like when we changed regress/GNUmakefile to pull rules from
Makefile.shlib, cygwin got broken in the process.
The problem is that regess.dll ends up being a symlink back to itself,
because we do a:
$(NAME)$(DLSUFFIX): $(shlib)
rm -f $(NAME)$(DLSUFFIX)
47 matches
Mail list logo
