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.
snip
Now, if there were
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
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/version/clustername/
It provides wrapper scripts to run pg_ctl (pg_ctlcluster) on any
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:
CREATE
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
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 the
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
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
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,
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
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
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: :aliasname
Where * ==
{print | save to PDF | save to mumble 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
Hi, Ron,
Ron Peacetree wrote:
Where * ==
{print | save to PDF | save to mumble 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 TrackingTracing International AG
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 PRIMARY
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 is a
Markus Schaber wrote:
Hi, Ron,
Ron Peacetree wrote:
Where * ==
{print | save to PDF | save to mumble 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
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 TrackingTracing International AG
Dipl. Inf. | Software Development GIS
Fight against
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 think this is
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 the
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:
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;
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
snip
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
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 will
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
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 idea may not
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 means
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 :-(.
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:
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
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 go
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.
Well,
I hope in pg_dump there should be an option that will
dump a schema without the indexes (except of course primary indexes)
regards
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
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
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
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, all the
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
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
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 my
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
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
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
[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
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. Don't
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 the
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
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
a schema is
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
index is already defined. And
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 last summer
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
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
52 matches
Mail list logo
