Dear all,
Just a quick message about postgresql.conf auto-configuration.
When MySQL users test PostgreSQL, they load their data and run simple
SQL queries. If postgresql.conf is configured with default values, it
may produce slow results.
Would there be a way for postgresql.conf to auto
Le mercredi 26 août 2009 à 15:51 -0700, Josh Berkus a écrit :
I doubt this would be an accurate description of all Drupal
developers.
My opinion was :
Before adding replication to PostgreSQL, it would be better to support a
basic set of MySQL syntax seems relevant:
DELETE FROM table1, table2
Le jeudi 27 août 2009 à 14:27 -0500, Jaime Casanova a écrit :
the point was that if we simply were saying: hey! mysql can interpret
this, make postgres do the same then we could end up with a lot of
broken stuff... just because mysql users think is wonderful to not
have to write sane code...
Le mercredi 26 août 2009 à 01:36 -0600, Rick Gigger a écrit :
One possible reason that replication is more critical now than it
was
a year ago is the rise in cloud computing. The ability to fire up
instances on demand is much more useful when some of those boxes can
be database servers
Le mercredi 26 août 2009 à 10:07 -0400, Andrew Dunstan a écrit :
Isn't that cast effectively a no-op?
What is no-op in English (I am French, pardon my English).
I will update table definition in 5 minutes.
Stay tuned.
Kind regards,
Jean-Michel
signature.asc
Description: Ceci est une partie
Dear friends,
Thank you for your previous answers. I am running into a systemic
problem using Drupal under PostgreSQL 8.4
Drupal relies heavily on a domain derived from int:
CREATE DOMAIN int_unsigned
AS integer
CONSTRAINT int_unsigned_check CHECK ((VALUE = 0));
Analysing slow queries, I
Le mercredi 26 août 2009 à 09:16 -0500, Kevin Grittner a écrit :
Please repost with that the pgsql-performance list
Done: http://drupal.org/node/559986
Kind regards, JMP
signature.asc
Description: Ceci est une partie de message numériquement signée
Le mercredi 26 août 2009 à 09:30 -0500, Kevin Grittner a écrit :
It's not clear to me what you feel is needed. That could mean many
things
Dear Kevin,
I rarely post on Hackers, so I will try to explain:
* I use PostgreSQL since 1998.
* I took part in the development of pgAdmin 12.
* I
Dear Kevin
So when you talk about focusing on usablility improvements you mean
that priority should be given to supporting MySQL-specific syntax
extensions and ensuring that there are no queries where the MySQL
optimizer comes up with a more efficient plan than PostgreSQL?
Yes. PostgreSQL
Second, we're not going to support MySQL's *bugs* and *bad design
decisions* which is what lazy developers actually want; they want
something exactly the same as MySQL, including bugs. If they want
that,
they can use MySQL. We are not MySQL, and trying to out-MySQL MySQL
is
stupid, just
Le mercredi 26 août 2009 à 22:06 +0100, Greg Stark a écrit :
With your current approach you're likely to get dismissed out of hand,
not unlike what I can well believe happened in the Drupal world.
This is the case.
That
would be unfortunate because I think there are 2 or 3 real
improvements
Le mercredi 26 août 2009 à 16:56 -0400, Alvaro Herrera a écrit :
Have you tried Drupal 7? It's said to have many of these corrected.
Maybe you should stop wasting your time with 6.x.
I am running a large community on the Net and people would like to
migrate our framework to Drupal. We agreed
With proper foreign keys and ON DELETE CASCADE, why would supporting
such syntax even be necessary?
Porting existing abstraction layers from ANSI JOINs to ON DELETE CASCADE
is complicated.
What I don't get is why this is such a usability issue. Subqueries in
DELETE FROM work perfectly well,
Dear Friends,
First, thank you very much for considering a fix on the GROUP BY issue.
I am starting a new thread about another issue:
It seems that DELETE cannot understand INNER JOINS and needs HAVING.
Read:
http://drupal.org/node/62 (main message)
http://drupal.org/node/555648
I don't
Dear friends,
I have been using PostgreSQL since 6.3 releases and I am a real fan.
Of course, I never use nor trust MySQL to deliver data.
Now I use Drupal 6.3 with PostgreSQL 8.4.
I loose a lot of time correcting Drupal SQL.
You may be interested in my developer feedback.
I gathered some
I've registered for the Drupal site so that I can fix and/or expand
some
of your items.
Thanks. I corrected the index on dual fields page.
If you want to discuss Drupal PostgreSQL again, please post on the
pgsql-advocacy list or the pgsql-php mailing lists. pgsql-hackers
isn't
the best
Thank you all for these kind answers. Cheers, JMP
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Dear friends,
You may know me as I worked a long time ago on pgAdmin I with Dave.
As this is an XML related question and XML is quite new, I am posting
on hackers ML. If any solution is being developped, please inform us.
We would like to develop a free REST database (real-estate standard)
Dear friends,
You may know me as I worked a long time ago on pgAdmin I with Dave.
As this is an XML related question and XML is quite new, I am posting
on hackers ML.
We would like to develop a free REST database (real-estate standard)
based on a PostgreSQL schema. This is a free solution for
of choice.
I don't ask for more.
Now, I hope that the list can return to a more peaceful state.
Kind regards,
Jean-Michel Pouré
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
€ and
500€.
Kind regards and happy new year.
Jean-Michel Pouré
---(end of broadcast)---
TIP 6: explain analyze is your friend
. by a factor of 10 or more.
Kind regards and happy new year.
I hope that 2008 will be the year of materialized views.
Jean-Michel Pouré
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Dear friends and all,
Johnathan Gardner did a wonderful job on materialized views:
http://jonathangardner.net/PostgreSQL/materialized_views/matviews.html
Are there any plans to integrate materialized views written in plain C in the
future. This can help gain a lot of time in Web applications.
Dear friends and all,
Johnathan Gardner did a wonderful job on materialized views:
http://jonathangardner.net/PostgreSQL/materialized_views/matviews.html
Are there any plans to integrate materialized views written in plain C in the
future. This can help gain a lot of time in Web applications.
24 matches
Mail list logo
