I would like to ask the more experienced users on Postgres database a
couple of questions I have on a db I manage with a lot of data. A lot of
data means something like 15.000.000 rows in a table. I will try to
describe the tables and what I will have to do on them :)
There is a table that has
Oleg Teodor,
If I understand the code correctly, GiST will only pass the first
attribute of each index tuple to the user-defined PickSplit method when
it wants to split a node. (see circa line 1269 of gist.c)
Is this a wise design decision? Granted, in many situations the first
attribute in
Hi,
this query makes postmaster (beta4) die with signal 11:
(echo CREATE TABLE footest(;
for i in `seq 0 66000`; do
echo col$i int NOT NULL,;
done;
echo PRIMARY KEY(col0));) | psql test
ERROR: tables can have at most 1600 columns
LOG: server process (PID 2140)
Joachim Wieland wrote:
this query makes postmaster (beta4) die with signal 11:
(echo CREATE TABLE footest(;
for i in `seq 0 66000`; do
echo col$i int NOT NULL,;
done;
echo PRIMARY KEY(col0));) | psql test
ERROR: tables can have at most 1600 columns
LOG: server
On Wed, 2004-11-10 at 22:51, Andrew Sullivan wrote:
On Wed, Nov 10, 2004 at 09:52:17PM +, Simon Riggs wrote:
On Wed, 2004-11-10 at 21:48, Richard Huxton wrote:
Isn't that:
log_min_duration_statement (integer)
That gets written when a statement completes, not during
On Fri, 2004-11-12 at 23:13, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Greg Stark wrote:
I think that's already done for CREATE INDEX/REINDEX.
I don't think so. Can someone confirm?
Greg is correct --- at least for btree build, which is the only index
type we have
On Sun, 2004-11-14 at 10:05, Neil Conway wrote:
Joachim Wieland wrote:
this query makes postmaster (beta4) die with signal 11:
(echo CREATE TABLE footest(;
for i in `seq 0 66000`; do
echo col$i int NOT NULL,;
done;
echo PRIMARY KEY(col0));) | psql test
On Fri, 2004-11-12 at 23:13, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Greg Stark wrote:
I think that's already done for CREATE INDEX/REINDEX.
I don't think so. Can someone confirm?
Greg is correct --- at least for btree build, which is the only index
type we have
When 8.0 is released, TIP 9 should change from
TIP 9: the planner will ignore your desire to choose an index scan if
your joining column's datatypes do not match
to
TIP 9: the planner will ignore your desire to choose an index scan if
your joining column's datatypes do not match (upgrade to
Who maintains the tips?
, 14/11/2004 11:31 +, Simon Riggs :
When 8.0 is released, TIP 9 should change from
TIP 9: the planner will ignore your desire to choose an index scan if
your joining column's datatypes do not match
to
TIP 9: the planner will ignore your desire to choose
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2004-11-12 at 23:13, Tom Lane wrote:
Greg is correct --- at least for btree build, which is the only index
type we have WAL-ified at all :-(
Is there a place (or a single best place) to document this behaviour?
If you're talking about the lack of
Joe Conway wrote:
I'm not sure exactly what has changed, nor at the moment how to fix it,
but I'm finding that pgxs no longer works for PL/R or dblink. Error as
follows:
make: *** No rule to make target
`/usr/local/pgsql-dev/lib/pgxs/src/makefiles/../../src/port/pg_config_paths.h',
needed by
A remember specifically that I somewhat recently fixed psql to accept
editors with arguments, say EDITOR=pico -t. This was apparently
broken again during some Windows-related reshuffling. It now takes the
editor as one quoted string rather than possibly several shell tokens.
Could this
Peter Eisentraut [EMAIL PROTECTED] writes:
A remember specifically that I somewhat recently fixed psql to accept
editors with arguments, say EDITOR=pico -t. This was apparently
broken again during some Windows-related reshuffling. It now takes the
editor as one quoted string rather than
Tom Lane wrote:
I think the rationale was to allow paths containing spaces, which is
a pretty serious problem on Windows. Seems like we have two basic
options:
1. Quote only on Windows.
2. Expect user to put quotes in the EDITOR value if it contains a
space-containing path.
The EDITOR
Peter Eisentraut [EMAIL PROTECTED] writes:
The EDITOR variable seems to have a fairly standard meaning on Unix
systems. I've been using that EDITOR value for years without problems,
only when I use psql's \e once in a while it breaks. I don't think we
should deviate from what seems to be
Bruce Momjian [EMAIL PROTECTED] writes:
OK, Tom please go ahead with the patch.
Done.
regards, tom lane
---(end of broadcast)---
TIP 8: explain analyze is your friend
1. Quote only on Windows.
2. Expect user to put quotes in the EDITOR value if it contains a
space-containing path.
As far I I'm aware, the options on windows are very much like those on
unix:
path containing spaces or
path\ containing\ spaces
Kind Regards
John Hansen
On 11/10/2004 11:57 PM, Mark Kirkwood wrote:
Your example and ones like :
SELECT max(foo), count(foo) FROM bar
SELECT max(a.foo1), max(b.foo2) FROM bar1 AS a NATURAL JOIN bar2 AS b
have made me realize that the scope of what should be optimized is
somewhat subtle.
I am inclined to keep it simple
On Sun, 2004-11-14 at 11:06 +, Simon Riggs wrote:
HASH - works OK, but a pain to administer, no huge benefit in using
At least in theory, I think this could offer better performance for
equality searches than b+-tree. Given how common those kinds of queries
are, I still think hash indexes
Neil Conway [EMAIL PROTECTED] writes:
This specific assertion is triggered because we represent attribute
numbers throughout the code base as a (signed) int16 -- the assertion
failure has occurred because an int16 has wrapped around due to
overflow. A fix would be to add a check to
Hello Peter,
I was about to update initdb translation, but noticed
that newly introduced error messages in the code have
German-style quotes. These propagated to the .po files now...
It happened in this commit:
On Sun, 2004-11-14 at 22:59, Neil Conway wrote:
On Sun, 2004-11-14 at 11:06 +, Simon Riggs wrote:
HASH - works OK, but a pain to administer, no huge benefit in using
At least in theory, I think this could offer better performance for
equality searches than b+-tree. Given how common
Serguei Mokhov [EMAIL PROTECTED] writes:
I was about to update initdb translation, but noticed
that newly introduced error messages in the code have
German-style quotes. These propagated to the .po files now...
Good catch; fix committed. A quick grep confirms these are
the only two cases.
Neil Conway [EMAIL PROTECTED] writes:
If I understand the code correctly, GiST will only pass the first
attribute of each index tuple to the user-defined PickSplit method when
it wants to split a node. (see circa line 1269 of gist.c)
Is this a wise design decision?
It's probably just a
Kris Jurka [EMAIL PROTECTED] writes:
I have an underpowered server running 7.2.6 that backs a website which
occasionally gets hit by a bunch of traffic and starts firing off FATAL
1: Sorry, too many clients already messages. This is all as expected,
but sometimes it just crashes. I had no
On Sun, 14 Nov 2004, Tom Lane wrote:
The comment in ProcGetNewSemIdAndNum suggests that you might be able to
suppress the problem in 7.2 by using a different max_connections value.
Is your current value one less than a multiple of 16, by any chance?
Currently 32. It is unclear whether
Kris Jurka [EMAIL PROTECTED] writes:
On Sun, 14 Nov 2004, Tom Lane wrote:
Is your current value one less than a multiple of 16, by any chance?
Currently 32. It is unclear whether you think 31 is the failure case your
thinking of or whether 31 might help.
No, 32 is actually the best case
John Hansen wrote:
1. Quote only on Windows.
2. Expect user to put quotes in the EDITOR value if it contains a
space-containing path.
As far I I'm aware, the options on windows are very much like those on
unix:
path containing spaces or
path\ containing\ spaces
My guess is
On Sun, 2004-11-14 at 18:54 -0500, Tom Lane wrote:
It's probably just a hangover from the days when GiST didn't support
multi-column indexes at all. I agree it should be changed.
I'm not sure the right way to fix it (at least without significant
changes to the GiST API). At present, the
hi,
As for mac os x this is on darwin mac os (it's mac something)
I ran a find command with a space in it.
mechatronics:~ joe$ find . -name '* *'
./backups/dscpadmin/scriptsMay19/dscp/validate/List of Cancers.doc
./backups/pain/PAINjune/validate/List of Cancers.doc
./backups/untarhere/test/List
Jan Wieck [EMAIL PROTECTED] writes:
Both cases can be expressed with order by + limit queries, that would indeed
utilize those indexes. But what's been discussed so far does not cover any of
them.
I think people should get away from thinking about order by + limit. That
isn't going to work
On 7.4:
This is what we wanted to do:
IF TG_OP = 'INSERT' OR (TG_OP = 'UPDATE' AND NEW.name != OLD.name) THEN
EXECUTE x;
END IF;
However, we had to write it like this:
IF TG_OP = 'INSERT' THEN
EXECUTE x;
ELSIF TG_OP = 'UPDATE' AND NEW.name != OLD.name THEN
EXECUTE x;
END IF;
Because in the
On 15 Nov 2004 02:00:37 -0500, Greg Stark [EMAIL PROTECTED] wrote:
I think people should get away from thinking about order by + limit. That
isn't going to work for anything with a GROUP BY. And it isn't going to work
for anything more complex than a single min() or max().
min() only needs
34 matches
Mail list logo
