Hello all,
I am working on a search-related project where scaling is a major issue.
Recently I've been experimenting with the beautifully designed rd-tree
indexes and intarray contrib module, and it seems like a great solution for
me.
I've hit a few bumps and am looking for clarification fr
2007/6/9, Gregory Stark <[EMAIL PROTECTED]>:
There has been some interesting research on sorting using the GPU which could
be very interesting for databases.
However I think Postgres would be unlikely to go the route of having compiled
driver code for every possible video card. It's unlikely to
On Thu, Jun 07, 2007 at 10:16:25AM -0400, Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > Thinking about this whole idea a bit more, it occured to me that the
> > current approach to write all, then fsync all is really a historical
> > artifact of the fact that we used to use
It is documented that intbig utilizes 4096 bit signatures to represent
the set nodes in the tree. However, I am unable to find any reference
to a 4kbit signature in the code and am wondering where this is implemented.
_int.h:
/* bigint defines */
#define SIGLENINT 63 /* >122 => key w
2007/6/9, Dann Corbit <[EMAIL PROTECTED]>:
#include
double log10nfactorialestimate(unsigned n)
{
unsignedi;
double estimate = 0;
for (i = 1; i < n; i++)
estimate += log10(n);
return estimate;
}
#ifdef UNIT_TEST
#include
#include
int
> -Original Message-
[snip]
> Hum... I think there is a little improvement: when n is too large,(say
> n>10, 000) we can use Stirling's formula to get the estimated value of
> n!:-)
Or (rather) the log base 10 of Stirling's formula. The n! estimator
will overflow for sure, unless we t
Hi,
Tom Lane wrote:
We *have* a log-writing process. The problem is in getting the data to it.
Remember the imessages approach I'm using for Postgres-R? It passes
messages around using shared memory and signals the receiver on incoming
data. It's not perfect, sure, but it's a general soluti
yeah, simple and correct, I like that. :-)
2007/6/9, Dann Corbit <[EMAIL PROTECTED]>:
> -Original Message-
[snip]
> Hum... I think there is a little improvement: when n is too large,(say
> n>10, 000) we can use Stirling's formula to get the estimated value of
> n!:-)
Or (rather) the
Gregory Stark wrote:
"Billings, John" <[EMAIL PROTECTED]> writes:
Does anyone think that PostgreSQL could benefit from using the video
card as a parallel computing device? I'm working on a project using
Nvidia's CUDA with an 8800 series video card to handle non-graphical
algorithms. I'm curio
Markus Schiltknecht <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> We *have* a log-writing process. The problem is in getting the data to it.
> Remember the imessages approach I'm using for Postgres-R? It passes
> messages around using shared memory and signals the receiver on incoming
> data
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> We *have* a log-writing process. The problem is in getting the data to it.
> By that I assume you mean the bgwriter, I thought that was for WAL data,
No, I'm talking about src/backend/postmaster/syslogger.c
On Sat, June 9, 2007 07:36, Gregory Stark wrote:
> "Billings, John" <[EMAIL PROTECTED]> writes:
>
>> Does anyone think that PostgreSQL could benefit from using the video
>> card as a parallel computing device? I'm working on a project using
>> Nvidia's CUDA with an 8800 series video card to handle
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> Why was it decided that binary mode is not allowed for stdin or stdout?
Works fine when using V3 frontend protocol. The old protocol for it
isn't 8-bit-clean.
regards, tom lane
---(end of broadcast)-
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Jim C. Nasby wrote:
>> On Tue, Jun 05, 2007 at 05:52:39PM -, Andrew Hammond wrote:
>>> +1. Given the prevalence of the pg_foo convention, those names are
>>> clunky. So is initdb. I'm less creative than Zdenek, so I'd suggest
>>> simply renaming t
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> So at the very least the documentation is confusing:
> The type numeric can store numbers with up to 1000 digits of precision
> and perform calculations exactly.
This documentation is outright wrong. The grain of truth behind the
statement is that the
Tom Lane wrote:
Markus Schiltknecht <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
We *have* a log-writing process. The problem is in getting the data to it.
Remember the imessages approach I'm using for Postgres-R? It passes
messages around using shared memory and signals the receiver on inco
1 Compiling from .sbl by original Snowball's makefile requires Perl and
doesn't work cleanly:
AFAIK, you don't receive any answers on your email in snowball mailing list.
2 Snowball's compiling infrastructure doesn't support Windows target.
3 I understand your wish about including only real s
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> 2 Snowball's compiling infrastructure doesn't support Windows target.
Yeah. Another problem with using their original source code is that
running the Snowball compiler during build would not work for
cross-compiled builds of Postgres, at least not witho
On Fri, Jun 08, 2007 at 08:12:22PM -0500, Jim C. Nasby wrote:
> On Tue, Jun 05, 2007 at 05:52:39PM -, Andrew Hammond wrote:
> > On Jun 5, 9:19 am, [EMAIL PROTECTED] (Alvaro Herrera) wrote:
> > > Zdenek Kotala wrote:
> > > > Tom Lane wrote:
> > > > >Bruce Momjian <[EMAIL PROTECTED]> writes:
> >
I've been looking at the updatable-cursors patch
http://archives.postgresql.org/pgsql-patches/2007-05/msg00264.php
which attempts to implement the SQL-spec UPDATE/DELETE WHERE CURRENT OF
syntax. It's pretty much of a mess, but there are some salvageable
ideas. There are two big things I don't lik
I know we have talked about how to avoid legal email signatures on this
list. One idea would be for a small percentage of our users to ignore
emails with a legal signature. I know I am less likely to reply to such
an email.
If enough people do that, it might coerce people to avoid them, and
perh
Hi,
I was looking to start development on the following TODO entry.
Add a separate TRUNCATE permission
Currently only the owner can TRUNCATE a table because triggers are not called,
and the table is locked in exclusive mode.
Does anyone have any objections? Looks like there is a change freez
Nick Barr <[EMAIL PROTECTED]> writes:
> I was looking to start development on the following TODO entry.
> Add a separate TRUNCATE permission
Is there actually a use-case for that? It seems like mostly pointless
complication to me. (Note that in the role world, one can effectively
have a table ow
23 matches
Mail list logo
