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
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 first
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
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 o
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 PickS
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\
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 c
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:
> 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 h
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
"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 c
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
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:
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/bin/initdb/initdb.c.diff?r1=1.
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 Def
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 ar
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 simpl
> > 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
--
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
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 t
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 ED
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
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 ple
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 `
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
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 d
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 8.0
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
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));") |
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
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 d
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: serve
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
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 t
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
34 matches
Mail list logo
