Tom Lane wrote:
worse --- in the first place there are severe performance issues
associated with unindexed foreign-key checks, and in the second place
there is the foot-gun problem that you might forget to re-add the
indexes at all.
MySQL has a syntax in ALTER TABLE similar to PGSQL's DISABLE/
On Feb 24, 2006, at 13:25 , Gavin Sherry wrote:
On Feb 23, 2006, at 11:40 , Gavin Sherry wrote:
I do think that unit testing of areas such as data types would be
useful,
particularly the date/time code and arrays as I consider that area
of the
code quite fragile. I wouldn't expect the unit t
On Thu, Feb 23, 2006 at 11:32:05PM -0500, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > Do we actually need this functionality inside the
> > DBMS in the first place?
>
> I think that is the $64 question. My immediate instinct is "no".
> See the knock-down-drag-out fights we had
Simply because it took me more or less 24 hours to restore the dump when
the
index is already defined. And it would only take less than an hour to
restore the
data without the index then create the index that would only take less
than 10 minutes.
BTW I am using postgresql 8.1.3
You still hav
I think the right question to ask here is "why are you so intent onusing separate schema/data restores?" That's not the recommended way
to go about things, and it never will be.regards,
tom laneSimply because it took me more or less 24 hours to restore the dump when the
in
"Jan Cruz" <[EMAIL PROTECTED]> writes:
> On 2/24/06, Michael Glaesemann <[EMAIL PROTECTED]> wrote:
>> If this doesn't do what you want, can you give a bit more
>> explanation? Also, what are you trying to do with this dump file?
> I also want an option that would exclude "CREATE INDEX " whenever
Neil Conway <[EMAIL PROTECTED]> writes:
> Do we actually need this functionality inside the
> DBMS in the first place?
I think that is the $64 question. My immediate instinct is "no".
See the knock-down-drag-out fights we had last summer about whether
to expose any filesystem access in built-in
On Fri, 24 Feb 2006, Michael Glaesemann wrote:
> [I neglected to cc the list in my reply earlier. Apologies to Gavin
> for the double-post.]
>
> On Feb 23, 2006, at 11:40 , Gavin Sherry wrote:
>
>
> > I do think that unit testing of areas such as data types would be
> > useful,
> > particularly t
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Incidentally, shouldn't the existing RI queries (eg. SELECT ... FOR
> SHARE) explicity specify operator(pg_catalog.=)?
Then they'd be guaranteed to fail for datatypes/operators created in
other schemas, rather than only at risk of failing. Do
[I neglected to cc the list in my reply earlier. Apologies to Gavin
for the double-post.]
On Feb 23, 2006, at 11:40 , Gavin Sherry wrote:
I do think that unit testing of areas such as data types would be
useful,
particularly the date/time code and arrays as I consider that area
of the
c
Kevin Grittner wrote:
Peter Brant, a consultant working with us, has written code which is
working for this under both Linux and Windows. [...] For Linux, he
used statvfs.
statvfs(2) is standardized, but doesn't seem portable: it isn't
available on OSX 10.3, NetBSD 2.0 or OpenBSD, for example
On Feb 24, 2006, at 10:44 , Andrew Dunstan wrote:
Much better than this, you can do a custom dump and then use
pg_restore's --list and --use-list features to remove the things
you don't want restored. pg_restore is wonderfully flexible.
That is nifty! Wow! Thanks, Andrew!
Michael Glaesema
No, there's no need for that. It means that the RI stuff would have to
take whatever steps we agree on to determine the exact comparison
operator to use, and then be sure to emit SQL that will select exactly
that operator --- this involves using the OPERATOR(foo.=) syntax to
remove schema-ambigui
Jim C. Nasby wrote:
On Fri, Feb 24, 2006 at 07:58:38AM +0800, Jan Cruz wrote:
On 2/24/06, Michael Glaesemann <[EMAIL PROTECTED]> wrote:
--schema-only flag is the equivalence of -s
I also want an option that would exclude "CREATE INDEX " whenever
a schema is being dump
At least on
Kevin Grittner wrote:
So, my questions:
(1) Did I miss something regarding mingw support for statvfs?
(2) If not, is it acceptable for a source file to contain that much
#if code for Windows?
I should probably also ask a tertiary question. His implementation
reports space in 1K increments
Kevin Grittner wrote:
(2) If not, is it acceptable for a source file to contain that much
#if code for Windows?
Large chunks of platform-specific code usually go in src/port
100 lines for a WIN32 piece would not be out of order there.
If that proves difficult, let us see the mods and
On Fri, Feb 24, 2006 at 07:58:38AM +0800, Jan Cruz wrote:
> On 2/24/06, Michael Glaesemann <[EMAIL PROTECTED]> wrote:
> --schema-only flag is the equivalence of -s
>
> I also want an option that would exclude "CREATE INDEX " whenever
> a schema is being dump
At least on my small test database,
On 2/24/06, Michael Glaesemann <[EMAIL PROTECTED]> wrote:
Have you looked at the --schema-only flag?http://www.postgresql.org/docs/current/interactive/app-pgdump.htmlIf this doesn't do what you want, can you give a bit more
explanation? Also, what are you trying to do with this dump file?Michael Gl
As part of integrating PostgreSQL into our production environment, we're
working on monitoring software, to provide the same kinds of status
reporting and alerts we have implemented for our outgoing commercial
database product. One of the things we show on our "big board" is
impending failure cond
On Feb 24, 2006, at 8:39 , Jan Cruz wrote:
I hope in pg_dump there should be an option that will
dump a schema without the indexes (except of course primary indexes)
Have you looked at the --schema-only flag?
http://www.postgresql.org/docs/current/interactive/app-pgdump.html
If this doesn't
I hope in pg_dump there should be an option that will
dump a schema without the indexes (except of course primary indexes)
regards
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Crazy ideas: add a #warning or #error to the header file unless there is
> > some special symbol previously defined, something like
> > #define I_UNDERSTAND_MEM_ALLOC_IN_TUPLETABLESLOT
> > which means the developer did update his code
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Crazy ideas: add a #warning or #error to the header file unless there is
> some special symbol previously defined, something like
> #define I_UNDERSTAND_MEM_ALLOC_IN_TUPLETABLESLOT
> which means the developer did update his code.
Well, if we wanted to g
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I've been modifying tuplesort.c to keep all the sort's local data in a
> >> separate memory context, to simplify and speed up cleaning up the data
> >> during tuplesort_end.
>
> > Is it possible to make the Tuple
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I've been modifying tuplesort.c to keep all the sort's local data in a
>> separate memory context, to simplify and speed up cleaning up the data
>> during tuplesort_end.
> Is it possible to make the TupleTableSlot not free the tuple
>
Tom Lane wrote:
> I've been modifying tuplesort.c to keep all the sort's local data in a
> separate memory context, to simplify and speed up cleaning up the data
> during tuplesort_end. I thought this would be a straightforward change,
> but was disillusioned when I got a core dump while testing :
Tom Lane wrote:
> Any thoughts about details? My feeling is that we should tie RI
> semantics to btree opclasses, same as we have done for ORDER BY
> and some other SQL constructs, but I don't have a concrete proposal
> right offhand. The btree idea may not cover cross-type FKs anyway.
This mea
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Any thoughts about details? My feeling is that we should tie RI
>> semantics to btree opclasses, same as we have done for ORDER BY
>> and some other SQL constructs, but I don't have a concrete proposal
>> right offhand. The btree ide
I've been modifying tuplesort.c to keep all the sort's local data in a
separate memory context, to simplify and speed up cleaning up the data
during tuplesort_end. I thought this would be a straightforward change,
but was disillusioned when I got a core dump while testing :-(. On
investigation th
On Thu, 23 Feb 2006, Tom Lane wrote:
> I looked into the problem reported here:
> http://archives.postgresql.org/pgsql-admin/2006-02/msg00261.php
> To wit, a pg_restore of a foreign key constraint involving user-defined
> types produces
>
> pg_restore: WARNING: foreign key constraint "luuid_fkey"
On Thu, Feb 23, 2006 at 01:10:07PM -0500, Tom Lane wrote:
> I looked into the problem reported here:
> http://archives.postgresql.org/pgsql-admin/2006-02/msg00261.php
> This has been a hazard in the RI code since day one, of course, but
> I think it's time to face up to it and do something about
I'll second autodoc. Been using it with Docbook and Dia for over a year
with good results.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Andrew Dunstan
> Sent: Thursday, February 23, 2006 12:00 PM
> To: Markus Schaber
> Cc: Ron Peacetree; pgs
I looked into the problem reported here:
http://archives.postgresql.org/pgsql-admin/2006-02/msg00261.php
To wit, a pg_restore of a foreign key constraint involving user-defined
types produces
pg_restore: WARNING: foreign key constraint "luuid_fkey" will require costly
sequential scans
DETAIL: K
On Thu, 23 Feb 2006, Pavel Stehule wrote:
> >
> >Right, but does the pattern_ops one have to be unique?
> Sorry, I don't uderstand
Are you trying to guarantee uniqueness on the pattern_ops rules. My
understanding is that pattern_ops is not just a special index that allows
like comparisons using
On Thu, 2006-02-23 at 11:54 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > A patch prototype to make zero_damaged_pages work as advertised is
> > enclosed, though the current behaviour may well be preferred, in which
> > case a doc patch is more appropriate.
>
> I don't thin
Hi, Andrew,
Andrew Dunstan wrote:
> How on earth can either of these have to do with producing an ERD?
Sorry, the ERD thing got lost in my mind while resolving the "*".
Markus
--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf. | Software Development GIS
Fight agains
Markus Schaber wrote:
Hi, Ron,
Ron Peacetree wrote:
Where "*" ==
{print | save to PDF | save to format | display on screen}
Anyone know of one?
psql with fancy output formatting comes to my mind, or "COPY table TO
file" SQL command.
How on earth can either of these have
Simon Riggs <[EMAIL PROTECTED]> writes:
> A patch prototype to make zero_damaged_pages work as advertised is
> enclosed, though the current behaviour may well be preferred, in which
> case a doc patch is more appropriate.
I don't think this is a good idea, and even if it were, the proposed
patch
Markus Schiltknecht <[EMAIL PROTECTED]> writes:
> I'm trying to speed up a query with a lookup table. This lookup table
> gets very big and should still fit into memory. It does not change very
> often. Given these facts I decided to use an array, as follows:
> CREATE TABLE lookup_table (id INT PR
Hi, Ron,
Ron Peacetree wrote:
> Where "*" ==
> {print | save to PDF | save to format | display on screen}
>
> Anyone know of one?
psql with fancy output formatting comes to my mind, or "COPY table TO
file" SQL command.
HTH,
Markus
--
Markus Schaber | Logical Tracking&Tracing International AG
Where "*" ==
{print | save to PDF | save to format | display on screen}
Anyone know of one?
TiA
Ron
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Michael Fuhr <[EMAIL PROTECTED]> writes:
> In an up-to-date HEAD server that was initdb'd on 12 Feb (catalog
> version 200602112):
> test=> SELECT * FROM pg_roles;
> ERROR: unrecognized token: ":aliasname"
> test=> SELECT pg_get_viewdef('pg_roles'::regclass, true);
> ERROR: unrecognized token: "
In an up-to-date HEAD server that was initdb'd on 12 Feb (catalog
version 200602112):
test=> SELECT * FROM pg_roles;
ERROR: unrecognized token: ":aliasname"
test=> SELECT pg_get_viewdef('pg_roles'::regclass, true);
ERROR: unrecognized token: ":aliasname"
This breaks several things, including pg
Hi Martijn!
Martijn van Oosterhout [2006-02-23 13:33 +0100]:
> What I mean is that only root can run pg_createcluster (either via
> package installation or directly). At least, that's what my reading of
> the code tells me. Uless you have an pg_adoptcluster somewhere :)
Ah, right, now I know what
There appears to be some issues or at least a lack of clarity with the
way we zero damaged/missing pages in various circumstances.
1. If we have an invalid page header then we execute the code below
(from bufmgr.c ReadBuffer()).. In the case that we are only reading the
page, not writing to it,
On Thu, Feb 23, 2006 at 12:42:52PM +0100, Martin Pitt wrote:
> > The main downside of this system is that some sysadmin pretty much
> > needs to create the clusters for everyone.
>
> What do you mean in particular? The packages install a default cluster
> (e. g. postgresql-8.1 creates a cluster 8.
Hello Oleg,
On Thu, 2006-02-23 at 15:02 +0300, Oleg Bartunov wrote:
> have you seen contrib/intarray ?
Yes, but in the documentation I did not find anything like
'generate_series' or thelike. Maybe I'm looking at the wrong place,
please give me a hint.
Regards
Markus
Hello Martijn,
On Thu, 2006-02-23 at 12:44 +0100, Martijn van Oosterhout wrote:
> > SELECT i.id, i.title FROM item i
> > JOIN lookup_table lut ON i.id = ANY(lut.items)
> > WHERE lut.id = $LOOKUP_ID;
>
> At the very least you're going to have to tell us which version you are
> running plus
Markus,
have you seen contrib/intarray ?
Oleg
On Thu, 23 Feb 2006, Markus Schiltknecht wrote:
Hi,
I'm trying to speed up a query with a lookup table. This lookup table
gets very big and should still fit into memory. It does not change very
often. Given these facts I decided to use an
On Thu, Feb 23, 2006 at 12:36:35PM +0100, Markus Schiltknecht wrote:
> Hi,
>
> I'm trying to speed up a query with a lookup table. This lookup table
> gets very big and should still fit into memory. It does not change very
> often. Given these facts I decided to use an array, as follows:
>
> CREA
Hi Mark, hi Martijn!
Martijn van Oosterhout [2006-02-23 12:10 +0100]:
> If you're talking about standards perhaps you should consider how
> Debian does it. All configuration is stored in
>
> /etc/postgresql///
>
> It provides wrapper scripts to run pg_ctl (pg_ctlcluster) on any
> particular clu
Hi,
I'm trying to speed up a query with a lookup table. This lookup table
gets very big and should still fit into memory. It does not change very
often. Given these facts I decided to use an array, as follows:
CREATE TABLE lookup_table (id INT PRIMARY KEY, items INT[] NOT NULL);
I know this is n
On Wed, Feb 22, 2006 at 09:22:14AM -0500, Mark Woodward wrote:
> That's not the issue.
> I find it frustrating sometimes because when I describe one scenario,
> people debate it using other scenarios. Maybe I lack the communications
> skills to convey the problem accurately.
> Now, if there were
53 matches
Mail list logo
