Am 2008-10-17 12:13:00, schrieb Mikkel Høgh:
> Besides, the if the Reply-To thing is so dangerous, why do most other
> mailing lists do it?
Curently I am on 117 Mailinglists and ONLY 2 Winsuck lists do this crap.
So, from what are you talking about?
Thanks, Greetings and nice Day/Evening
Mi
Am 2008-10-16 23:17:35, schrieb Mikkel Høgh:
> P.S.: Why are e-mails from this list not sent with a Reply-To: header
> of the lists e-mail-address?
Because if I hit I want to send a private message and if I
hit it goes to the list andthe all
people get bulk-mail from me?
If you hav
At 09:42 PM 10/14/2008, you wrote:
Mikkel Høgh wrote:
On 14/10/2008, at 11.40, Ivan Sergio Borgonovo wrote:
That might be true, if the only demographic you
are looking for are professional DBAs, but if
you're looking to attract more developers, not
having sensible defaults is not really a g
On 2008-10-17 12:13, Mikkel Høgh wrote:
>> You're supposed to use "Reply to all" if you want to reply to the
>> list.
>
> Well, I think the most common use case for a mailing list is to reply
> back to the list, isn't that the whole point?
It is a point of having "Reply to all" button. With "r
On 17/10/2008, at 11.37, Tomasz Ostrowski wrote:
On 2008-10-16 23:17, Mikkel Høgh wrote:
P.S.: Why are e-mails from this list not sent with a Reply-To: header
of the lists e-mail-address?
Because it is dangerous - too easy to send to the list, when you
really
mean to send to one. Most e-m
On 2008-10-16 23:17, Mikkel Høgh wrote:
> P.S.: Why are e-mails from this list not sent with a Reply-To: header
> of the lists e-mail-address?
Because it is dangerous - too easy to send to the list, when you really
mean to send to one. Most e-mail programs have two buttons for replying:
ordinar
On 16/10/2008, at 18.27, Scott Marlowe wrote:
On Thu, Oct 16, 2008 at 9:26 AM, Stephen Frost <[EMAIL PROTECTED]>
wrote:
* DelGurth ([EMAIL PROTECTED]) wrote:
Seems Tomasz linked to the wrong patch. The patch he meant was:
http://drupal.org/files/issues/drupal_lookup_path-6.x.patch.txt
That'
On Thu, Oct 16, 2008 at 9:26 AM, Stephen Frost <[EMAIL PROTECTED]> wrote:
> * DelGurth ([EMAIL PROTECTED]) wrote:
>> Seems Tomasz linked to the wrong patch. The patch he meant was:
>> http://drupal.org/files/issues/drupal_lookup_path-6.x.patch.txt
>
> That's much better.
>
>> Also nice to see peopl
On 2008-10-16 16:40, Stephen Frost wrote:
There is an issue report with lengthy discussion on drupal.org:
http://drupal.org/node/196862
And a proposed patch:
I don't see 'limit 1' anywhere in that patch..
Sorry - haven't checked it - I have checked only a 6.x version
http://drupal.org/files/
* DelGurth ([EMAIL PROTECTED]) wrote:
> Seems Tomasz linked to the wrong patch. The patch he meant was:
> http://drupal.org/files/issues/drupal_lookup_path-6.x.patch.txt
That's much better.
> Also nice to see people "benchmark" differences by just executing a
> query once[2][3]
This thread i
On Thu, Oct 16, 2008 at 4:40 PM, Stephen Frost <[EMAIL PROTECTED]> wrote:
> * Tomasz Ostrowski ([EMAIL PROTECTED]) wrote:
> I don't see 'limit 1' anywhere in that patch.. And you don't want to
> use 'limit 1' *and* count(*), that doesn't do what you're expecting
> (since count(*) is an aggregate a
* Tomasz Ostrowski ([EMAIL PROTECTED]) wrote:
> There is an issue report with lengthy discussion on drupal.org:
> http://drupal.org/node/196862
> And a proposed patch:
> http://drupal.org/files/issues/drupal_lookup_path-5.x.patch.txt
> which uses "limit 1". This patch is not applied though. I don't
Ivan Sergio Borgonovo <[EMAIL PROTECTED]> writes:
> I wonder if pg is using ssl even on sockets.
No, it won't do that.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/
On Tue, 14 Oct 2008 18:44:56 +0200
Ivan Sergio Borgonovo <[EMAIL PROTECTED]> wrote:
> BTW I hope someone may find good use of this:
> 2xXeon HT CPU 3.20GHz (not dual core), 4Gb RAM, RAID 5 SCSI
> * absolutely not tuned Apache
> * absolutely not tuned Drupal with little content, some blocks and
>
On 2008-10-16 10:34, Mikkel Hogh wrote:
> It's not only to avoid one query, but to avoid one query every time
> drupal_lookup_path() is called (which is every time the system builds
> a link, which can be dozens of time on a page).
Oh, $count is static. My bad. Using count for testing for emp
It's not only to avoid one query, but to avoid one query every time
drupal_lookup_path() is called (which is every time the system builds
a link, which can be dozens of time on a page).
So, I think it's probably a worthwhile tradeoff on MyISAM, because
such queries are fast there, and you p
On 2008-10-14 23:57, Mikkel Hogh wrote:
> one is the dreaded "SELECT COUNT(pid) FROM
> url_alias" which takes PostgreSQL a whopping 70.65ms out of the
> 115.74ms total for 87 queries.
This is stupid.
The Drupal code looks like this:
// Use $count to avoid looking up paths in subsequent call
Tom Lane wrote:
> "Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Mind you, I find the SysV APIs uselessly baroque too, but there is one
> >> feature that we have to have that is not in mmap(): the ability to
> >> detect other processes attached to a shmem block.
>
> > D
Tom Lane wrote:
I think the subtext there is that the Linux kernel hackers hate the SysV
IPC APIs and wish they'd go away. They are presently constrained from
removing 'em by their desire for POSIX compliance, but you won't get
them to make any changes that might result in those APIs becoming mo
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Mind you, I find the SysV APIs uselessly baroque too, but there is one
>> feature that we have to have that is not in mmap(): the ability to
>> detect other processes attached to a shmem block.
> Didn't we solve this problem on
Greg Smith <[EMAIL PROTECTED]> writes:
> If there were ever any Linux distributions that increased this value from
> the tiny default, you might have a defensible position here (maybe
> Oracle's RHEL fork does, they might do something here). I've certainly
> never seen anything besides Solaris
On Wed, 15 Oct 2008, Gregory Stark wrote:
Greg Smith <[EMAIL PROTECTED]> writes:
DB2 has automatically updated the "shmmax" kernel
parameter from "33554432" to the recommended value "268435456".
This seems like a bogus thing for an application to do though.
It happens when y
Gregory Stark <[EMAIL PROTECTED]> writes:
> Greg Smith <[EMAIL PROTECTED]> writes:
>> DB2 has automatically updated the "shmmax" kernel
>> parameter from "33554432" to the recommended value "268435456".
> This seems like a bogus thing for an application to do though. The Redhat
> people seem happy
Greg Smith <[EMAIL PROTECTED]> writes:
> DB2 has automatically updated the "shmmax" kernel
> parameter from "33554432" to the recommended value "268435456".
This seems like a bogus thing for an application to do though. The Redhat
people seem happy with the idea but I'm pretty sure
Martin Gainty <[EMAIL PROTECTED]> writes:
> MG>comments prefixed with MG>
Incidentally that's a good way to make sure people don't see your comments.
There are a few variations but the common denominator is that things prefixed
with "foo>" are quotations from earlier messages. Many mailers hide
On Tue, Oct 14, 2008 at 6:15 PM, Chris <[EMAIL PROTECTED]> wrote:
>
>> Are you saying you have to reconnect to change schemas? In Oracle and
>> PostgreSQL both you can change the current schema (or schemas for
>> postgresql) with a single inline command.
>
> No I meant you have to change the schem
Are you saying you have to reconnect to change schemas? In Oracle and
PostgreSQL both you can change the current schema (or schemas for
postgresql) with a single inline command.
No I meant you have to change the schema after connecting.
Some hosts only give you one db & one user. Yeh it suck
On Tue, Oct 14, 2008 at 4:35 PM, Chris <[EMAIL PROTECTED]> wrote:
>
>> Note this comment:
>> /*
>> * Queries sent to Drupal should wrap all table names in curly brackets.
>> This
>> * function searches for this syntax and adds Drupal's table prefix to all
>> * tables, allowing Drupal to coexist
Note this comment:
/*
* Queries sent to Drupal should wrap all table names in curly brackets. This
* function searches for this syntax and adds Drupal's table prefix to all
* tables, allowing Drupal to coexist with other systems in the same database if
* necessary.
*/
That's an MySQL-ism for
On Tue, 14 Oct 2008, Kevin Murphy wrote:
One thing that might help people swallow the off-putting default "toy
mode" performance of PostgreSQL would be an explanation of why
PostgreSQL uses its shared memory architecture in the first place.
I doubt popularizing the boring technical details be
On 14/10/2008, at 23.22, Merlin Moncure wrote:
On Tue, Oct 14, 2008 at 5:04 PM, Mikkel Høgh <[EMAIL PROTECTED]> wrote:
After disabling SSL for localhost, I ran the tests again, and the
performance gap is reduced to about 30%.
ok, now consider you are on a read only load, with lots (if I read
On Tue, Oct 14, 2008 at 5:04 PM, Mikkel Høgh <[EMAIL PROTECTED]> wrote:
> After disabling SSL for localhost, I ran the tests again, and the
> performance gap is reduced to about 30%.
ok, now consider you are on a read only load, with lots (if I read the
thread correctly) repetitive queries. mysql
After disabling SSL for localhost, I ran the tests again, and the
performance gap is reduced to about 30%.
--
Kind regards,
Mikkel Høgh <[EMAIL PROTECTED]>
On 14/10/2008, at 21.17, Magnus Hagander wrote:
Mikkel Høgh wrote:
On 14/10/2008, at 20.23, Daniel Verite wrote:
What I've noticed on
forwarding here too cos I just got the copy sent to my personal
address and just much later the one from pg list... + adding some
more siege run.
On Tue, 14 Oct 2008 19:05:42 +0200
Mikkel Høgh <[EMAIL PROTECTED]> wrote:
> Hmm, those are interesting numbers. Did you use a real, logged
> in, drupal
Mikkel Høgh wrote:
> On 14/10/2008, at 20.23, Daniel Verite wrote:
>> What I've noticed on drupal-6.4 with Ubuntu 8.04 is that the default
>> postgresql.conf has:
>> ssl=true
>> and since drupal doesn't allow connecting to pgsql with unix socket
>> paths [1], what you get by default is probably TCP
On Tue, Oct 14, 2008 at 08:23:47PM +0200, Daniel Verite wrote:
> [1] A patch has been posted here: http://drupal.org/node/26836 , but it
> seems to have gotten nowhere. The comments about pg_connect() are
> depressingly lame, apparently nobody had a clue how unix socket files
> should be specifi
On Tue, Oct 14, 2008 at 12:39 PM, Mikkel Høgh <[EMAIL PROTECTED]> wrote:
> On 14/10/2008, at 20.23, Daniel Verite wrote:
>>
>> What I've noticed on drupal-6.4 with Ubuntu 8.04 is that the default
>> postgresql.conf has:
>> ssl=true
>> and since drupal doesn't allow connecting to pgsql with unix soc
On 14/10/2008, at 20.23, Daniel Verite wrote:
What I've noticed on drupal-6.4 with Ubuntu 8.04 is that the default
postgresql.conf has:
ssl=true
and since drupal doesn't allow connecting to pgsql with unix socket
paths [1], what you get by default is probably TCP + SSL encryption.
A crude tes
Mikkel Høgh wrote:
In any case, if anyone has any tips, input, etc. on how best to
configure PostgreSQL for Drupal, or can find a way to poke holes in
my
analysis, I would love to hear your insights :)
I'm a recent Drupal user with postgres.
What I've noticed on drupal-6.4 with Ub
On Oct 13, 2008, at 2:08 AM, admin wrote:
Can anyone recommend an alternative CMS with the features and
flexibility of Drupal that supports PostgreSQL 100%? What about the
Python world, what is Plone like with PostgreSQL support?
Look at using either Pylons or Turbogears with SQLAlchemy if
On Tue, Oct 14, 2008 at 7:47 AM, Ang Chin Han <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 14, 2008 at 8:56 PM, Scott Marlowe <[EMAIL PROTECTED]> wrote:
>> On Tue, Oct 14, 2008 at 3:40 AM, Ivan Sergio Borgonovo
>> <[EMAIL PROTECTED]> wrote:
>>> On Mon, 13 Oct 2008 20:45:39 -0600
>>> "Joshua Tolley" <[E
--
Med venlig hilsen,
Mikkel Høgh <[EMAIL PROTECTED]>
On 14/10/2008, at 17.28, Ang Chin Han wrote:
On Tue, Oct 14, 2008 at 10:05 PM, Martin Gainty
<[EMAIL PROTECTED]> wrote:
Yes, it's rather braindead. I'd rather not worry about why, but how'd
we make Drupal use the PostgreSQL more effectiv
Hmm, those are interesting numbers. Did you use a real, logged in,
drupal session ID (anonymous users also get one, which still gives
them cached pages).
They are in the form of
"SESS6df8919ff2bffc5de8bcf0ad65f9dc0f=59f68e60a120de47c2cb5c98b010"
Note how the thoughput stays in the 30-
On Tue, 14 Oct 2008 06:56:02 -0600
"Scott Marlowe" <[EMAIL PROTECTED]> wrote:
> >> This is a useful question, but there are reasonable answers to
> >> it. The key underlying principle is that it's impossible to
> >> know what will work well in a given situation until that
> >> situation is tested.
On Tue, Oct 14, 2008 at 10:05 PM, Martin Gainty <[EMAIL PROTECTED]> wrote:
> MG>comments prefixed with MG>
> MG>What about INNODB is Drupal forgetting the default engine for 5.x?
I don't use MySQL for drupal myself except for testing, but Drupal
just uses the default storage engine for MySQL, whi
Greg Smith wrote:
On Tue, 14 Oct 2008, Mikkel H�gh wrote:
You are targetting DBAs using servers with less than 512 MB RAM. Is
PostgreSQL supposed to be used by professional DBAs on enterprise
systems or is it supposed to run out of the box on my old Pentium 3?
you'll discover that the Linux
On Tue, 14 Oct 2008 06:42:33 -0700
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
> Mikkel Høgh wrote:
> > On 14/10/2008, at 11.40, Ivan Sergio Borgonovo wrote:
>
> > That might be true, if the only demographic you are looking for
> > are professional DBAs, but if you're looking to attract more
> >
On 14/10/2008, at 16.05, Martin Gainty wrote:
> The benchmark is a mostly read-only Drupal site -- a few admins,
but a
> lot of readers. Drupal as a benchmark is skewed towards lots and
lots
> of small, simple queries, which MyISAM excels at. The long term fix
> ought to be to help the Drupal
MG>comments prefixed with MG>
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: [GENERAL] Drupal and PostgreSQL - performance issues?
> CC: [EMAIL PROTECTED]; pgsql-general@postgresql.org
>
> On Tue, Oct 14, 2008 at 8:56 PM, Scott Marlowe <[EMAIL PR
On Tue, 14 Oct 2008, Mikkel H?gh wrote:
You are targetting DBAs using servers with less than 512 MB RAM. Is
PostgreSQL supposed to be used by professional DBAs on enterprise
systems or is it supposed to run out of the box on my old Pentium 3?
Take a look at http://bugzilla.kernel.org/show_bug
On Tue, Oct 14, 2008 at 8:56 PM, Scott Marlowe <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 14, 2008 at 3:40 AM, Ivan Sergio Borgonovo
> <[EMAIL PROTECTED]> wrote:
>> On Mon, 13 Oct 2008 20:45:39 -0600
>> "Joshua Tolley" <[EMAIL PROTECTED]> wrote:
>>
>> Premise:
>> I'm not sustaining that the "default"
Mikkel Høgh wrote:
On 14/10/2008, at 11.40, Ivan Sergio Borgonovo wrote:
That might be true, if the only demographic you are looking for are
professional DBAs, but if you're looking to attract more developers, not
having sensible defaults is not really a good thing.
While I'll probably take t
On Tue, 14 Oct 2008, Ivan Sergio Borgonovo wrote:
The fact that out of the box on common hardware PostgreSQL under-perform
MySQL with default config would matter if few paragraph below you
wouldn't say that integrity has a *big* performance cost even on
read-only operation.
If you want a mor
On 14/10/2008, at 11.40, Ivan Sergio Borgonovo wrote:
On Mon, 13 Oct 2008 20:45:39 -0600
"Joshua Tolley" <[EMAIL PROTECTED]> wrote:
PostgreSQL ships with a very conservative default configuration
because (among other things, perhaps) 1) it's a configuration
that's very unlikely to fail miserab
On Tue, Oct 14, 2008 at 3:40 AM, Ivan Sergio Borgonovo
<[EMAIL PROTECTED]> wrote:
> On Mon, 13 Oct 2008 20:45:39 -0600
> "Joshua Tolley" <[EMAIL PROTECTED]> wrote:
>
> Premise:
> I'm not sustaining that the "default" answers are wrong, but they are
> inadequate.
> BTW the OP made a direct compariso
On Mon, 13 Oct 2008 20:45:39 -0600
"Joshua Tolley" <[EMAIL PROTECTED]> wrote:
Premise:
I'm not sustaining that the "default" answers are wrong, but they are
inadequate.
BTW the OP made a direct comparison of pgsql and mysql running
drupal. That's a bit different than just asking: how can I improve
On Mon, Oct 13, 2008 at 1:02 AM, Ivan Sergio Borgonovo
<[EMAIL PROTECTED]> wrote:
> Anyway I don't find myself comfortable with replies in these 2 lines
> of reasoning:
> 1) default configuration of PostgreSQL generally doesn't perform well
> 2) PostgreSQL may be slower but mySQL may trash your da
ly endorse content contained within this transmission.
> CC: pgsql-general@postgresql.org
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: [GENERAL] Drupal and PostgreSQL - performance issues?
> Date: Mon, 13 Oct 2008 10:45:17 -0400
>
>
> On Oct 13, 2008, at 5:
John DeSoi wrote:
On Oct 13, 2008, at 5:08 AM, admin wrote:
However, PostgreSQL support in the PHP CMS world seems lacking. Joomla
is basically a MySQL-only shop. Drupal is *maybe* suitable, but who
really knows where it will end up?
My hope is that Drupal is moving in the right direction.
On Oct 13, 2008, at 5:08 AM, admin wrote:
However, PostgreSQL support in the PHP CMS world seems lacking.
Joomla is basically a MySQL-only shop. Drupal is *maybe* suitable,
but who really knows where it will end up?
My hope is that Drupal is moving in the right direction. With version
6
On Oct 13, 2008, at 4:08 AM, admin wrote:
I am also evaluating Drupal + PostgreSQL at the moment. We are
building a local government website/intranet that doesn't need to be
lightning fast or handle millions of hits a day, but it does need to
be rock solid and potentially needs to manage c
On Mon, Oct 13, 2008 at 10:08 AM, admin <[EMAIL PROTECTED]> wrote:
> I am also evaluating Drupal + PostgreSQL at the moment. We are building a
> local government website/intranet that doesn't need to be lightning fast or
> handle millions of hits a day, but it does need to be rock solid and
> pote
I am also evaluating Drupal + PostgreSQL at the moment. We are building
a local government website/intranet that doesn't need to be lightning
fast or handle millions of hits a day, but it does need to be rock solid
and potentially needs to manage complex business processes. So
PostgreSQL seems
On Sun, 12 Oct 2008 22:14:53 -0700
"Uwe C. Schroeder" <[EMAIL PROTECTED]> wrote:
> > I have been testing it a bit performance-wise, and the numbers
> > are worrying. In my test, MySQL (using InnoDB) had a 40% lead in
> > performance, but I'm unsure whether this is indicative for
> > PostgreSQL per
> I have been testing it a bit performance-wise, and the numbers are
> worrying. In my test, MySQL (using InnoDB) had a 40% lead in
> performance, but I'm unsure whether this is indicative for PostgreSQL
> performance in general or perhaps a misconfiguration on my part.
In my experience the "numbe
On Oct 12, 2008, at 11:57 PM, Mikkel Høgh wrote:
In any case, if anyone has any tips, input, etc. on how best to
configure PostgreSQL for Drupal, or can find a way to poke holes in
my analysis, I would love to hear your insights :)
I just came across this article about moving Drupal from
Hi there,
I've been toying with using PostgreSQL for some of my Drupal sites for
some time, and after his session at OpenSourceDays in Copenhagen last
weekend, Magnus Hagander told me that there a quite a few in the
PostgreSQL community using Drupal.
I have been testing it a bit performan
On Sat, 14 Jan 2006, John DeSoi wrote:
> > In the meantime.. can anybody around here shed any light on using
> > the Drupal ecommerce module with postgreSQL?
>
> I have used parts of the module (primarily the address management) and
> I did not find it difficult to port for PostgreSQL. It ap
On Jan 14, 2006, at 2:46 PM, [EMAIL PROTECTED] wrote:
I'm probably going to connect Drupal to mysql and play some more.
If we
end up using it I'm leaning toward converting the ecommerce module
table
definition file from mysql to postgreSQL, I'll cross that bridge
when we
come to it.
In
All.
After reading about the Drupal CMS using mysql *OR* postgreSQL I've been
experimenting with it, setting it up with postgreSQL and playing.
Another fellow and I are considering using it more, but when we loaded the
ecommerce module we could only find a table definition file for
mysql.
70 matches
Mail list logo
