On Fri, May 19, 2006 at 07:04:47PM -0400, Bruce Momjian wrote:
> > libreadline is not a problem because you can distribute postgresql
> > compiled with readline and comply with all licences involved
> > simultaneously. It doesn't work with openssl because the licence
> > requires things that are in
Tom Lane <[EMAIL PROTECTED]> writes:
> If it did that might be a nice solution, but I'm not sure that it does
> use B-M ... I can't find either "Boyer" or "Moore" in its source code.
>
> There's no particular reason to suppose offhand that a regex engine
> would be faster than the naive code for
Get pg_trgm http://www.sai.msu.su/~megera/oddmuse/index.cgi/ReadmeTrgm
It doesn't depends on language.
Oleg
On Fri, 19 May 2006, Mark Woodward wrote:
I have a side project that needs to "intelligently" know if two strings
are contextually similar. Think about how CDDB information is collected
a
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>> I have a side project that needs to "intelligently" know if two strings
>> are contextually similar.
>
> The examples you gave seem heavy on word order and whitespace
> consideration,
> before applying any algorithms. Here's a quick perl ve
Applied by Alvaro. Thanks.
---
Larry Rosenman wrote:
> Larry Rosenman wrote:
> > Greetings,
> > I've got a patch to be reviewed for having the stats system keep
> > track of the last
> > time a table was vacuumed or anal
Hi,
suppose we have something like this:
upd_views=# create table tabla1 (col1 point);
CREATE TABLE
upd_views=# insert into tabla1 values ('3,2');
INSERT 0 1
upd_views=# insert into tabla1 values ('2,2');
INSERT 0 1
upd_views=# insert into tabla1 values ('3,2');
INSERT 0 1
then, this select wil
Hannu Krosing wrote:
> I had a (false ?) memory that we used some variant of pcre, and that
> pcre uses BM. I may be false on both accounts. (I know that python
> borrowed its re module from pcre).
Our code is a derivative from Henry Spencer's code found in Tcl. It
certainly isn't Boyer Moore,
> > I have a side project that needs to "intelligently" know if two
> > strings are contextually similar.
Also check out the "fuzzystrmatch" module in /contrib, which offers
soundex, metaphone and levenschtein functions.
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
--
Joshua D. Drake wrote:
> Jonah H. Harris wrote:
> > On 5/19/06, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> >> And with that, I am going to sit in a lawn chair and watch the bonfire.
> >
> > This is one of the finest examples of unfocused discussions I've ever
> > seen on -hackers... while surely
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Fri, May 19, 2006 at 04:41:20PM -0400, Bruce Momjian wrote:
> > > Yes, the exeption applies to libreadline, which is why we can deliver
> > > psql with libreadline linked on Linux, for example. But we can't on
> > > Windows or Sol
Ühel kenal päeval, L, 2006-05-20 kell 01:34, kirjutas Hannu Krosing:
> Ühel kenal päeval, R, 2006-05-19 kell 18:18, kirjutas Tom Lane:
> > Hannu Krosing <[EMAIL PROTECTED]> writes:
> > > I guess our regex implementation already uses boyer-moore or similar.
> > > Why not just expose the match positi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> I have a side project that needs to "intelligently" know if two strings
> are contextually similar.
The examples you gave seem heavy on word order and whitespace consideration,
before applying any algorithms. Here's a quick perl version that does
Ühel kenal päeval, R, 2006-05-19 kell 22:53, kirjutas Martijn van
Oosterhout:
> libreadline is not a problem because you can distribute postgresql
> compiled with readline and comply with all licences involved
> simultaneously.
oh? my impression was that we are clear, because libreadline is just
Ühel kenal päeval, R, 2006-05-19 kell 18:18, kirjutas Tom Lane:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > I guess our regex implementation already uses boyer-moore or similar.
> > Why not just expose the match position of substring('text' in 'regex')
> > using some function, called match_pos
Ühel kenal päeval, R, 2006-05-19 kell 14:57, kirjutas Jim C. Nasby:
> On Fri, May 19, 2006 at 09:29:44PM +0200, Martijn van Oosterhout wrote:
> > On Fri, May 19, 2006 at 10:02:50PM +0300, Hannu Krosing wrote:
> > > > > It's just SELECT count(*) FROM (SELECT * FROM accounts ORDER BY bid)
> > > > >
Hannu Krosing <[EMAIL PROTECTED]> writes:
> I guess our regex implementation already uses boyer-moore or similar.
> Why not just expose the match position of substring('text' in 'regex')
> using some function, called match_position(int searched_text, int
> regex, int matchnum) ?
If it did that mi
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> True random data wouldn't be such a great test either; what would
> probably be best is a set of random words, since in real life you're
> unlikely to have truely random data.
True random data would provide worst-case compression behavior, so
we'd want
Jonah H. Harris wrote:
On 5/19/06, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
And with that, I am going to sit in a lawn chair and watch the bonfire.
This is one of the finest examples of unfocused discussions I've ever
seen on -hackers... while surely entertaining, what a huge waste of
time.
On 5/19/06, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
And with that, I am going to sit in a lawn chair and watch the bonfire.
This is one of the finest examples of unfocused discussions I've ever
seen on -hackers... while surely entertaining, what a huge waste of
time.
--
Jonah H. Harris, So
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Ãhel kenal päeval, R, 2006-05-19 kell 16:12, kirjutas Jim C. Nasby:
>> IIRC, Oracle handles this by allowing you to prefix variables with the
>> name of the function.
> what happens if your function name is the same as some table name or
> local recor
Ühel kenal päeval, R, 2006-05-19 kell 16:12, kirjutas Jim C. Nasby:
> On Fri, May 19, 2006 at 11:03:21PM +0300, Hannu Krosing wrote:
> > A less disruptive change would be to have some predefined "record" where
> > all local variables belong to, perhaps called 'local' or '_local_' :) so
> > one coul
Ühel kenal päeval, R, 2006-05-19 kell 09:40, kirjutas Christopher
Kings-Lynne:
> > We also need better support for non C locales in tsearch. As I was porting
> > mysql's sakila sample database I was reminded just how painful it is when
> > you
> > initdb in a non-supported locale (which is prob
On Fri, May 19, 2006 at 11:03:21PM +0300, Hannu Krosing wrote:
> A less disruptive change would be to have some predefined "record" where
> all local variables belong to, perhaps called 'local' or '_local_' :) so
> one could access both input parameter inp_orderdate and declared
> variable var_orde
> Mark Woodward wrote:
>> I have a side project that needs to "intelligently" know if two strings
>> are contextually similar. Think about how CDDB information is collected
>> and sorted. It isn't perfect, but there should be enough information to
>> be
>> usable.
>>
>> Think about this:
>>
>> "pin
On Fri, May 19, 2006 at 04:41:20PM -0400, Bruce Momjian wrote:
> > Yes, the exeption applies to libreadline, which is why we can deliver
> > psql with libreadline linked on Linux, for example. But we can't on
> > Windows or Solaris.
>
> OK, where do you see this exception? I have not.
The exce
Mark Woodward wrote:
> I have a side project that needs to "intelligently" know if two strings
> are contextually similar. Think about how CDDB information is collected
> and sorted. It isn't perfect, but there should be enough information to be
> usable.
>
> Think about this:
>
> "pink floyd - d
Andrew Dunstan wrote:
> Bruce Momjian wrote:
> > Rod Taylor wrote:
> >
> >> Exceptions exist in the GPL for libraries and tools included in the
> >> operating system and this is enough in most cases. GPL applications on
> >> Windows may have problems.
> >>
> >
> > What exception, exactly?
Bruce Momjian wrote:
Rod Taylor wrote:
Exceptions exist in the GPL for libraries and tools included in the
operating system and this is enough in most cases. GPL applications on
Windows may have problems.
What exception, exactly? Does an exception apply to libreadline,
because list I
Rod Taylor wrote:
> Exceptions exist in the GPL for libraries and tools included in the
> operating system and this is enough in most cases. GPL applications on
> Windows may have problems.
What exception, exactly? Does an exception apply to libreadline,
because list I looked, it didn't.
--
B
Tom Lane wrote:
Josh Berkus writes:
Other projects need even more intensive coding help. OpenOffice, for example,
doesn't offer the Postgres driver by default because it's still too buggy.
That seems like something that it'd be worth our while to help fix.
+1 (or +10 if that's not to pig
Joshua D. Drake wrote:
> Robert Treat wrote:
> >On Friday 19 May 2006 14:22, Joshua D. Drake wrote:
> >>>Other projects need even more intensive coding help. OpenOffice, for
> >>>example, doesn't offer the Postgres driver by default because it's still
> >>>too buggy. That would be solvable with mo
Tom Lane wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
>
>>Tom Lane <[EMAIL PROTECTED]> writes:
>>
>>>And how much code would those take? The bottom line here is that we
>>>don't have a pile of complaints about the performance of text_position,
>>>so it's difficult to justify making it much mor
Ühel kenal päeval, R, 2006-05-19 kell 11:20, kirjutas Jim C. Nasby:
> On Thu, May 18, 2006 at 06:49:38PM -0700, Mark Dilger wrote:
> > > I would think that the worst-case times would be fairly improbable.
> > > I'm disinclined to push something as complicated as Boyer-Moore matching
> > > into this
Ühel kenal päeval, R, 2006-05-19 kell 14:39, kirjutas Jim C. Nasby:
> On Fri, May 19, 2006 at 09:57:29PM +0300, Hannu Krosing wrote:
> > ??hel kenal p??eval, R, 2006-05-19 kell 11:24, kirjutas Jim C. Nasby:
> >
> > > Something that's always bugged me is how horribly variables are handled
> > > in
[EMAIL PROTECTED] ("Mark Woodward") writes:
>> Jim C. Nasby wrote:
>>> Maybe a compatability layer isn't worth doing, but I certainly
>>> think it's very much worthwhile for the community to do everything
>>> possible to encourage migration from MySQL. We should be able to
>>> lay claim to most adv
On Fri, May 19, 2006 at 03:39:23PM -0400, Mark Woodward wrote:
> >
> >> Actually, I think it's a lot more accurate to compare PostgreSQL and
> >> MySQL as FreeBSD vs Linux from about 5 years ago. Back then FreeBSD was
> >> clearly superior from a technology standpoint, and clearly playing
> >> seco
Mark Woodward wrote:
(3) Is there also a desire for a Levenshtein distence function for text
and varchars? I experimented with it, and was forced to write the function
in item #1.
fuzzystrmatch in contrib already has a Levenshtein function.
cheers
andrew
---(end
Robert Treat wrote:
On Friday 19 May 2006 14:22, Joshua D. Drake wrote:
Other projects need even more intensive coding help. OpenOffice, for
example, doesn't offer the Postgres driver by default because it's still
too buggy. That would be solvable with money, but $1000 to $2000, not
$50.
Does
On Fri, May 19, 2006 at 09:29:44PM +0200, Martijn van Oosterhout wrote:
> On Fri, May 19, 2006 at 10:02:50PM +0300, Hannu Krosing wrote:
> > > > It's just SELECT count(*) FROM (SELECT * FROM accounts ORDER BY bid) a;
> > > > If the tape routines were actually storing visibility information, I'd
> >
On Fri, May 19, 2006 at 04:00:48PM -0400, Mark Woodward wrote:
> (3) Is there also a desire for a Levenshtein distence function for text
> and varchars? I experimented with it, and was forced to write the function
> in item #1.
Postgres already has a Levenshtein distence function, see fuzzystrmatc
I have a side project that needs to "intelligently" know if two strings
are contextually similar. Think about how CDDB information is collected
and sorted. It isn't perfect, but there should be enough information to be
usable.
Think about this:
"pink floyd - dark side of the moon - money"
"dark s
On Fri, May 19, 2006 at 09:57:29PM +0300, Hannu Krosing wrote:
> ??hel kenal p??eval, R, 2006-05-19 kell 11:24, kirjutas Jim C. Nasby:
>
> > Something that's always bugged me is how horribly variables are handled
> > in plpgsql, namely that if you have a variable and a field with the same
> > name
On Fri, 2006-05-19 at 14:44 -0400, Tom Lane wrote:
> Marc Munro <[EMAIL PROTECTED]> writes:
> > My proposal makes it possible for properly configured add-ins to have a
> > guaranteed amount of shared memory available.
>
> This could all be solved in a cleaner, more bulletproof way if you
> simply
On Fri, May 19, 2006 at 10:02:50PM +0300, Hannu Krosing wrote:
> ??hel kenal p??eval, R, 2006-05-19 kell 14:53, kirjutas Tom Lane:
> > "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > > On Fri, May 19, 2006 at 09:29:03AM +0200, Martijn van Oosterhout wrote:
> > >> I'm seeing 250,000 blocks being cut
On Fri, May 19, 2006 at 10:02:50PM +0300, Hannu Krosing wrote:
> > > It's just SELECT count(*) FROM (SELECT * FROM accounts ORDER BY bid) a;
> > > If the tape routines were actually storing visibility information, I'd
> > > expect that to be pretty compressible in this case since all the tuples
> >
>
>> Actually, I think it's a lot more accurate to compare PostgreSQL and
>> MySQL as FreeBSD vs Linux from about 5 years ago. Back then FreeBSD was
>> clearly superior from a technology standpoint, and clearly playing
>> second-fiddle when it came to users. And now, Linux is actually
>> technicall
On Friday 19 May 2006 14:22, Joshua D. Drake wrote:
> > Other projects need even more intensive coding help. OpenOffice, for
> > example, doesn't offer the Postgres driver by default because it's still
> > too buggy. That would be solvable with money, but $1000 to $2000, not
> > $50.
>
> Does it r
Ühel kenal päeval, R, 2006-05-19 kell 14:53, kirjutas Tom Lane:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > On Fri, May 19, 2006 at 09:29:03AM +0200, Martijn van Oosterhout wrote:
> >> I'm seeing 250,000 blocks being cut down to 9,500 blocks. That's almost
> >> unbeleiveable. What's in the tab
Ühel kenal päeval, R, 2006-05-19 kell 11:24, kirjutas Jim C. Nasby:
> Something that's always bugged me is how horribly variables are handled
> in plpgsql, namely that if you have a variable and a field with the same
> name it can be extremely difficult to keep them seperated. Perhaps := vs
> = mi
Moving to -advocacy, bcc to -hackers.
On Fri, May 19, 2006 at 08:11:42AM -0700, Joshua D. Drake wrote:
> When MySQL is at that
> >point, which database do you think executives will be choosing? The one
> >with a very large userbase and lots of marketing and PR that they've
> >heard plenty about,
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Fri, May 19, 2006 at 09:29:03AM +0200, Martijn van Oosterhout wrote:
>> I'm seeing 250,000 blocks being cut down to 9,500 blocks. That's almost
>> unbeleiveable. What's in the table? It would seem to imply that our
>> tuple format is far more compress
Actually, I think it's a lot more accurate to compare PostgreSQL and
MySQL as FreeBSD vs Linux from about 5 years ago. Back then FreeBSD was
clearly superior from a technology standpoint, and clearly playing
second-fiddle when it came to users. And now, Linux is actually
technically superior in
Marc Munro <[EMAIL PROTECTED]> writes:
> My proposal makes it possible for properly configured add-ins to have a
> guaranteed amount of shared memory available.
This could all be solved in a cleaner, more bulletproof way if you
simply require such add-ins to be preloaded into the postmaster proces
On Fri, May 19, 2006 at 11:29:23AM -0400, Mark Woodward wrote:
> I kind of agree with this statement, but while I was playing devils's
> advocate and just grousing a bit about having to use MySQL, there is a
> sort of reality of "openomics" where mind-share is everything.
>
> The more mind-share y
On Fri, May 19, 2006 at 09:29:03AM +0200, Martijn van Oosterhout wrote:
> On Thu, May 18, 2006 at 10:02:44PM -0500, Jim C. Nasby wrote:
> > http://jim.nasby.net/misc/compress_sort.txt is preliminary results.
> > I've run into a slight problem in that even at a compression level of
> > -3, zlib is c
On Fri, 2006-05-19 at 10:05 -0700, Josh Berkus wrote:
> Marc,
>
> > The add-in would not "know" how much had been allocated to it, but could
> > be told through it's own config file. I envisage something like:
> >
> > in postgresql.conf
> >
> > # add_in_shmem = 0# Amount of shared mem to set
Josh Berkus writes:
> Other projects need even more intensive coding help. OpenOffice, for
> example,
> doesn't offer the Postgres driver by default because it's still too buggy.
That seems like something that it'd be worth our while to help fix.
Does anyone have a handle on what the problem
Other projects need even more intensive coding help. OpenOffice, for example,
doesn't offer the Postgres driver by default because it's still too buggy.
That would be solvable with money, but $1000 to $2000, not $50.
Does it really need one since it supports JDBC and ODBC?
J
--
===
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> And how much code would those take? The bottom line here is that we
>> don't have a pile of complaints about the performance of text_position,
>> so it's difficult to justify making it much more complicated than it
>>
Tom Lane <[EMAIL PROTECTED]> writes:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> You've obviously missed the point of my concern, which is code bloat.
>
> > So why not just replace our code with better algorithms? We could use
> > Shift-Or or Shift-And which AFAIK are e
Michael,
Howdy, glad to see you came back.
> 1. We should treat all marketing efforts by hackers/programmers as
> social bugs. Get some marketing pros (debuggers) in on this, or the
> popularity of postgresql will continue to pale in the real world.
Not really in line with PostgreSQL's "person
On Fri, 2006-05-19 at 13:41 -0300, [EMAIL PROTECTED]
wrote:
> Marc Munro wrote:
> > Veil http://pgfoundry.org/projects/veil is currently not a very good
> > Postgres citizen. It steals what little shared memory it needs from
> > postgres' shared memory using ShmemAlloc().
> >
> > For Postgres 8.
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> You've obviously missed the point of my concern, which is code bloat.
> So why not just replace our code with better algorithms? We could use
> Shift-Or or Shift-And which AFAIK are even better than Boyer-Moore.
And how much code wo
Marc,
> The add-in would not "know" how much had been allocated to it, but could
> be told through it's own config file. I envisage something like:
>
> in postgresql.conf
>
> # add_in_shmem = 0 # Amount of shared mem to set aside for add-ins
> # in KBytes
> add_in_shem =
On Fri, 2006-05-19 at 13:41 -0300, [EMAIL PROTECTED]
wrote:
> On Thu, 2006-05-18 at 17:39 -0700, Marc Munro wrote:
>
> > For Postgres 8.2 I would like Veil to be a better citizen and use
> only
> > what shared memory has been reserved for postgres add-ins.
>
> How would Postgres ask the add-in ho
Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > Perhaps it would be best to add a seperate set of functions that use
> > boyer-moore, and reference them in appropriate places in the
> > documentation. Unless someone has a better idea on how we can find out
> > what people are actua
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Perhaps it would be best to add a seperate set of functions that use
> boyer-moore, and reference them in appropriate places in the
> documentation. Unless someone has a better idea on how we can find out
> what people are actually doing in the field...
On Fri, 2006-05-19 at 09:36 -0700, Jeff Frost wrote:
> On Fri, 19 May 2006, Tom Lane wrote:
>
> > What I'd suggest is resuming the test after making sure you've killed
> > off any old archivers, and seeing if you can make any progress on
> > reproducing the original problem. We definitely need a
On Fri, 19 May 2006, Tom Lane wrote:
What I'd suggest is resuming the test after making sure you've killed
off any old archivers, and seeing if you can make any progress on
reproducing the original problem. We definitely need a
multiple-archiver interlock, but I think that must be unrelated to
On Fri, 19 May 2006, Tom Lane wrote:
Well, the fact that there's only one archiver *now* doesn't mean there
wasn't more than one when the problem happened. The orphaned archiver
would eventually quit.
Do you have logs that would let you check when the production postmaster
was restarted?
I l
Alvaro Herrera wrote:
Joshua D. Drake wrote:
Martijn van Oosterhout wrote:
On Thu, May 18, 2006 at 02:58:11PM -0400, Mark Woodward wrote:
The reality is that MySQL is widely supported by some very, shall we say,
"interesting" open source projects and using these products with
PostgreSQL would
On Fri, 2006-05-19 at 12:03 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > OK, I'm on it.
>
> What solution have you got in mind? I was thinking about an fcntl lock
> to ensure only one archiver is active in a given data directory. That
> would fix the problem without affec
On Fri, 2006-05-19 at 09:11 -0700, Joshua D. Drake wrote:
> Martijn van Oosterhout wrote:
> > On Thu, May 18, 2006 at 02:58:11PM -0400, Mark Woodward wrote:
> >> The reality is that MySQL is widely supported by some very, shall we say,
> >> "interesting" open source projects and using these product
On Fri, 2006-05-19 at 12:20 -0400, Tom Lane wrote:
> I wrote:
> > Well, the fact that there's only one archiver *now* doesn't mean there
> > wasn't more than one when the problem happened. The orphaned archiver
> > would eventually quit.
>
> But, actually, nevermind: we have explained the failure
On Thu, May 18, 2006 at 08:40:04PM -0400, Douglas McNaught wrote:
> Mark Dilger <[EMAIL PROTECTED]> writes:
>
> > Tom Lane wrote:
> >> No it isn't. The plpgsql scanner treats := and = as *the same token*.
> >> They can be interchanged freely. This has nothing to do with the case
> >> of modifyin
Joshua D. Drake wrote:
Martijn van Oosterhout wrote:
On Thu, May 18, 2006 at 02:58:11PM -0400, Mark Woodward wrote:
The reality is that MySQL is widely supported by some very, shall we
say,
"interesting" open source projects and using these products with
PostgreSQL would be a plus.
The bigge
On Thu, May 18, 2006 at 06:49:38PM -0700, Mark Dilger wrote:
> > I would think that the worst-case times would be fairly improbable.
> > I'm disinclined to push something as complicated as Boyer-Moore matching
> > into this function without considerable evidence that it's a performance
> > bottlene
I wrote:
> Well, the fact that there's only one archiver *now* doesn't mean there
> wasn't more than one when the problem happened. The orphaned archiver
> would eventually quit.
But, actually, nevermind: we have explained the failures you were seeing
in the test setup, but a multiple-active-arch
Jeff Frost <[EMAIL PROTECTED]> writes:
> Hurray! Unfortunately, the postmaster on the original troubled server almost
> never gets restarted, and in fact only has only one archiver process running
> right now. Drat!
Well, the fact that there's only one archiver *now* doesn't mean there
wasn't m
Joshua D. Drake wrote:
> Martijn van Oosterhout wrote:
> >On Thu, May 18, 2006 at 02:58:11PM -0400, Mark Woodward wrote:
> >>The reality is that MySQL is widely supported by some very, shall we say,
> >>"interesting" open source projects and using these products with
> >>PostgreSQL would be a plus.
Martijn van Oosterhout wrote:
On Thu, May 18, 2006 at 02:58:11PM -0400, Mark Woodward wrote:
The reality is that MySQL is widely supported by some very, shall we say,
"interesting" open source projects and using these products with
PostgreSQL would be a plus.
The biggest headache I find with u
On Fri, 19 May 2006, Tom Lane wrote:
Well, there's our smoking gun. IIRC, all the failures you showed us are
consistent with race conditions caused by multiple archiver processes
all trying to do the same tasks concurrently.
Do you frequently stop and restart the postmaster? Because I don't s
Martijn van Oosterhout wrote:
The biggest headache I find with using postgres is that various GPL
licenced programs have trouble directly shipping postgresql support
because of our use of OpenSSL. Each and every one of those program
needs to add an exception to their licence for distributors to
Marc Munro wrote:
Veil http://pgfoundry.org/projects/veil is currently not a very good
Postgres citizen. It steals what little shared memory it needs from
postgres' shared memory using ShmemAlloc().
For Postgres 8.2 I would like Veil to be a better citizen and use only
what shared memory has be
On Fri, 2006-05-19 at 11:34 -0400, Tom Lane wrote:
[...]
>
> This only affects the 7.4 and 8.0 branches, because earlier and later
> versions of Postgres don't use this technique for detecting duplicates.
> But it's surprising we didn't find it before.
>
> Patches will appear in next week's r
Simon Riggs <[EMAIL PROTECTED]> writes:
> OK, I'm on it.
What solution have you got in mind? I was thinking about an fcntl lock
to ensure only one archiver is active in a given data directory. That
would fix the problem without affecting anything outside the archiver.
Not sure what's the most po
On Thu, 2006-05-18 at 17:39 -0700, Marc Munro wrote:
> For Postgres 8.2 I would like Veil to be a better citizen and use only
> what shared memory has been reserved for postgres add-ins.
How would Postgres ask the add-in how much memory it needs? How would
the add-in know how much has been reserv
On Thu, May 18, 2006 at 02:58:11PM -0400, Mark Woodward wrote:
> The reality is that MySQL is widely supported by some very, shall we say,
> "interesting" open source projects and using these products with
> PostgreSQL would be a plus.
The biggest headache I find with using postgres is that variou
Many thanks for allowing me to trace through your problem case.
It's a real Postgres bug, and a nasty one. The problem is a thinko in
nodeIndexscan.c's code that tests whether the same tuple has already
been emitted in a previous OR'd scan: it is looking for a match on
tuple->t_data->t_ctid, when
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> Mark Woodward wrote:
>>> Again, there is so much code for MySQL, a MySQL emulation layer, MEL
>>> for
>>> short, could allow plug and play compatibility for open source, and
>>> closed
>>> source, applications that otherwise would force a PostgreSQL u
When MySQL is at that
point, which database do you think executives will be choosing? The one
with a very large userbase and lots of marketing and PR that they've
heard plenty about,
All due respect, Jim -- but don't you work for a publicly traded
database company that happens to have its own
On Fri, May 19, 2006 at 01:26:34AM +0200, Dawid Kuroczko wrote:
> Personally my opinion is that there is no point in pushing PostgreSQL
> everywhere -- if there is no siginifcant performance gain, most managers
> will refuse it, on the grounds that "if it ain't (too) broke, don't fix it".
> The rea
Dragan Zubac <[EMAIL PROTECTED]> writes:
> Does anybody knows the Postgres v8.0.3 data directory hierarchy ? What is
> the purpose of the multiply files such as:
> 5
> 5.1
> 5.2
> 5.3
> each of the same size ?
http://developer.postgresql.org/docs/postgres/storage.html
Martijn van Oosterhout writes:
> However, postgres tables are very highly compressable, 10-to-1 is not
> that uncommon. pg_proc and pg_index compress by that for example.
> Indexes compress even more (a few on my system compress 25-to-1 but
> that could just be slack space, the record being 37-to-
On Fri, May 19, 2006 at 09:03:31AM -0400, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > I'm seeing 250,000 blocks being cut down to 9,500 blocks. That's almost
> > unbeleiveable. What's in the table?
>
> Yeah, I'd tend to question the test data being used. gzip does not do
> that well on
Dragan Zubac wrote:
> Hello
>
> Does anybody knows the Postgres v8.0.3 data directory hierarchy ?
> What is the purpose of the multiply files such as:
>
> 5
> 5.1
> 5.2
> 5.3
>
> each of the same size ?
>
those are the 1 gigabyte segments of your table/index/relation.
see the s
Hello
Does anybody knows the Postgres v8.0.3 data directory hierarchy ? What is
the purpose of the multiply files such as:
5
5.1
5.2
5.3
each of the same size ?
Sincerely
Dragan Zubac
---(end of broadcast)---
TIP 1: if posting/
Martijn van Oosterhout writes:
> I'm seeing 250,000 blocks being cut down to 9,500 blocks. That's almost
> unbeleiveable. What's in the table?
Yeah, I'd tend to question the test data being used. gzip does not do
that well on typical text (especially not at the lower settings we'd
likely want to
Jim,
> http://jim.nasby.net/misc/compress_sort.txt is preliminary results.
> I've run into a slight problem in that even at a compression
> level of -3, zlib is cutting the on-disk size of sorts by
> 25x. So my pgbench sort test with scale=150 that was
> producing a 2G on-disk sort is now prod
Am Freitag, 19. Mai 2006 02:35 schrieb Robert Treat:
> On Thursday 18 May 2006 12:38, Josh Berkus wrote:
> > Personally, I'd go after MSSQL before I bothered with MySQL. Sure,
> > let's make *migration* easier for those who wake up and smell the BS, but
> > migration can (and probably should) be
1 - 100 of 103 matches
Mail list logo
