Hello,
I'm finishing my career in computer engineering. To finish that I've
to develop a new implementation of R*-tree. My teacher Prof. Dr.
Seeger, http://dbs.mathematik.uni-marburg.de/Home/People/Professor has
already one done, now he wants me to add it to PostgreSQL using Gist.
Now that gist i
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> ... it would be OK to rewrite
> SELECT DISTINCT x ORDER BY foo(x)
> as
> SELECT DISTINCT ON (foo(x), x) x ORDER BY foo(x)
This assumes that x = y implies foo(x) = foo(y), which is something
that's not necessarily the case, mainly because a datatype's "
On Thu, May 04, 2006 at 01:13:20 -0400,
Tom Lane <[EMAIL PROTECTED]> wrote:
>
> I think it's a fair point that we could allow "SELECT DISTINCT x ORDER BY
> foo(x)" if foo() is stable, but that does not imply that sorting by x is
> interchangeable with sorting by foo(x). foo = abs is a trivial
>
On Thu, May 04, 2006 at 01:32:45 -0400,
Greg Stark <[EMAIL PROTECTED]> wrote:
> Bruno Wolff III <[EMAIL PROTECTED]> writes:
>
> > On Thu, May 04, 2006 at 00:05:16 -0400,
> > Greg Stark <[EMAIL PROTECTED]> wrote:
> > > Bruno Wolff III <[EMAIL PROTECTED]> writes:
> > >
> > > > > Whereas it shou
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> On Thu, May 04, 2006 at 00:05:16 -0400,
> Greg Stark <[EMAIL PROTECTED]> wrote:
> > Bruno Wolff III <[EMAIL PROTECTED]> writes:
> >
> > > > Whereas it shouldn't be hard to prove that this is equivalent:
> > > >
> > > > stark=> explain select col1 f
It's slightly annoying to have to read the flat file twice, but
for reasonable numbers of databases per installation I don't think
this will pose any material performance penalty. The file will
certainly still be sitting in kernel disk cache.
Dropping a db isn't exactly a "common" occurrence an
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> wrote [ baldly summarized ]
>> [ x > y implies upper(x) > upper(y) ]
> I don't think you can assume that that will be true for any locale.
Whether or not that may actually be true for upper() (I share Bruno's
skepticism,
On Thu, May 04, 2006 at 00:05:16 -0400,
Greg Stark <[EMAIL PROTECTED]> wrote:
> Bruno Wolff III <[EMAIL PROTECTED]> writes:
>
> > > Whereas it shouldn't be hard to prove that this is equivalent:
> > >
> > > stark=> explain select col1 from test group by upper(col1),col1 order by
> > > upper(co
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> > Whereas it shouldn't be hard to prove that this is equivalent:
> >
> > stark=> explain select col1 from test group by upper(col1),col1 order by
> > upper(col1);
> > QUERY PLAN
> > -
On Wed, May 03, 2006 at 17:58:07 -0400,
Greg Stark <[EMAIL PROTECTED]> wrote:
>
> Though it's optimized poorly and does a superfluous sort step:
>
> stark=> explain select col1 from test group by col1 order by upper(col1);
> QUERY PLAN
Actually, project mentioned on Oleg's page is only in plan.
I see some gap between current moment and the moment when GiST will
come to power for XML support - check out my proposal
(http://archives.postgresql.org/pgsql-hackers/2006-05/msg00044.php),
the 'minumum' list is that gap. When we will h
Normally Postgres extends SQL to allow ORDER BY to include arbitrary
expressions not in the select list. However this doesn't seem to work with
SELECT DISTINCT.
stark=> \d test
Table "public.test"
Column | Type | Modifiers
+--+---
col1 | text |
stark=>
Yes, there is no single way, because there are different tasks. There
are many papers on this theme.
I'm pretty sure that first of all we need to analyze other DBMSes'
experience. I'm working on it, analyzing MS, ORA and DB2 (first
results of analysis will be available in several weeks).
I've su
nice workaround, I am going to modify my procedure to drop the "public" schema
first (it is the largest one).
-- Original Message ---
From: "Tony Wasson" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: pgsql-hackers
Sent: Wed, 3 May 2006 14:09:05 -0700
Subject: Re: [HACKERS] drop
On 5/3/06, Jim Buttafuoco <[EMAIL PROTECTED]> wrote:
from time to time I have to drop a very large database (1TB+). The drop
database command takes a long time to complete
while its deleting the files. During this time, no one can connect to the database
server, ps displays "startup
waiting".
On 5/3/06, Robert Staudinger <[EMAIL PROTECTED]> wrote:
on your summer of code page [1] you outline a project "XML improvements".
Is there any relation (similar goals, feature overlapping, technical
relation) to the "pgxml" project mentioned for some time on [2]?
No, the XML project idea submit
This is motivated by Jim Buttafuoco's recent gripe about not being
able to connect while a DROP DATABASE is in progress:
http://archives.postgresql.org/pgsql-hackers/2006-05/msg00074.php
The whole area is really pretty grotty anyway --- the existing interlock
does not prevent an incoming connection
On Wed, May 03, 2006 at 10:12:28AM -0500, Jim C. Nasby wrote:
> On Tue, May 02, 2006 at 07:45:13PM -0700, elein wrote:
> > On Tue, May 02, 2006 at 12:00:42PM -0500, Jim C. Nasby wrote:
> > > On Mon, May 01, 2006 at 06:43:00PM -0700, elein wrote:
> > > > On Mon, May 01, 2006 at 07:47:06PM -0400, Tom
Tom,
I am trying to migrate all of my database from 7.4 to 8.1, It takes alot of
disk space to have both online at the same
time. I have done around 2TB of actual disk space to date and have another 6TB
to do over the next month or so. I have
been moving (with pg_dump 7.4db | pg_dump 8.1db) ea
> On Tue, May 02, 2006 at 05:49:33PM -0500, Jim C. Nasby wrote:
>> Back in the discussion of this someone had mentioned capturing all the
>> info that you'd get from a vacuum verbose; dead tuples, etc. What do
>> people think about that? In particular I think it'd be handy to know how
>> many pages
"Jim Buttafuoco" <[EMAIL PROTECTED]> writes:
> from time to time I have to drop a very large database (1TB+). The drop
> database command takes a long time to complete
> while its deleting the files. During this time, no one can connect to the
> database server, ps displays "startup
> waiting".
Jim C. Nasby wrote:
> On Wed, May 03, 2006 at 01:37:03PM -0400, Tom Lane wrote:
>> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>>> On Tue, May 02, 2006 at 11:06:59PM -0400, Tom Lane wrote:
Actually, the stats socket seems like a really good bet to me,
since all the backends will be interes
Hannu Krosing <[EMAIL PROTECTED]> writes:
> If you mean the full cycle, then it is probably not worth it, as even a
> single 'clean index' pass can take hours on larger tables.
The patch Heikki is working on will probably alleviate that problem,
because it will allow vacuum to scan the indexes in
On Wed, May 03, 2006 at 01:37:03PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > On Tue, May 02, 2006 at 11:06:59PM -0400, Tom Lane wrote:
> >> Actually, the stats socket seems like a really good bet to me, since all
> >> the backends will be interested in the same socket.
On Wed, May 03, 2006 at 07:06:09PM +0200, hubert depesz lubaczewski wrote:
> hi
> some time ago i was told on postgresql-general about existence of "hstore"
> package for postgresql.
> as i understand it is being developed by the same guys that are behind
> tsearch2, gin and (at least) recent chang
On Wed, May 03, 2006 at 03:54:57PM +0200, Martijn van Oosterhout wrote:
> On Tue, May 02, 2006 at 05:49:33PM -0500, Jim C. Nasby wrote:
> > Back in the discussion of this someone had mentioned capturing all the
> > info that you'd get from a vacuum verbose; dead tuples, etc. What do
> > people thin
hubert depesz lubaczewski wrote:
i have number of projects coming to my mind which could take advantage
of something like this. the simplest thing is e-commerce site, where all
custom fields (fields dependand on product type) can be stored in one,
easily retrievable, field - thus reducing data
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Tue, May 02, 2006 at 11:06:59PM -0400, Tom Lane wrote:
>> Actually, the stats socket seems like a really good bet to me, since all
>> the backends will be interested in the same socket. The
>> client-to-backend sockets are only touched by two process
hisome time ago i was told on postgresql-general about existence of "hstore" package for postgresql.as i understand it is being developed by the same guys that are behind tsearch2, gin and (at least) recent changes in gist.
would it be possible to include this software in main postgresql tarball? i
On Tue, May 02, 2006 at 11:06:59PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > Just experienced a server that was spending over 50% of CPU time in the
> > system, apparently dealing with postmasters that were in the sblock
> > state. Looking at the FreeBSD source, this i
On Tue, May 02, 2006 at 07:45:13PM -0700, elein wrote:
> On Tue, May 02, 2006 at 12:00:42PM -0500, Jim C. Nasby wrote:
> > On Mon, May 01, 2006 at 06:43:00PM -0700, elein wrote:
> > > On Mon, May 01, 2006 at 07:47:06PM -0400, Tom Lane wrote:
> > > > "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > >
On Tue, May 02, 2006 at 05:49:33PM -0500, Jim C. Nasby wrote:
> Back in the discussion of this someone had mentioned capturing all the
> info that you'd get from a vacuum verbose; dead tuples, etc. What do
> people think about that? In particular I think it'd be handy to know how
> many pages vacuu
from time to time I have to drop a very large database (1TB+). The drop
database command takes a long time to complete
while its deleting the files. During this time, no one can connect to the
database server, ps displays "startup
waiting". This is with Postgresql 7.4. Has this been addressed
Ühel kenal päeval, R, 2006-03-03 kell 11:37, kirjutas Tom Lane:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > So for you it would certainly help a lot to be able to vacuum the first
> > X pages of the big table, stop, release locks, create new transaction,
> > continue with the next X pages, lat
Dear PostgreSQL developer.
Although it is allowed to create a cast for a domain, it seems that there
is no way to trigger it. You can find attached an sql script to illustrate
the issue with postgresql 8.1.3. The create cast and create domain
documentations do not seem to discuss this point.
Hello,
on your summer of code page [1] you outline a project "XML improvements".
Is there any relation (similar goals, feature overlapping, technical
relation) to the "pgxml" project mentioned for some time on [2]? I
have been (remotely) following Oleg Bartunov's page on GiST usage and
datatypes
> > > I'm planning on continuing to increase XLOG_BLCKSZ and wal_buffers
to
> > > determine when the throughput starts to level out or drop
> >
> > I think for an even better comparison you should scale wal_buffers
> > down with increasing XLOG_BLCKSZ, so that the xlog buffer has a
fixed
> > siz
37 matches
Mail list logo
