Ühel kenal päeval, L, 2007-10-13 kell 17:44, kirjutas Gokulakannan
Somasundaram:
Hi,
I went through this article and it was good. Please have a look
at it.
http://www.databasecolumn.com/2007/09/one-size-fits-all.html
This article was written by Michael Stonebraker, considered to be
A Dissabte 13 Octubre 2007, Gokulakannan Somasundaram va escriure:
Even otherwise we are recommending Indexes with snapshot as an option. We
are not replacing the current index scheme. So if someone feels that his
database should run on lesser disk space, let them create the normal index.
If
* Gregory Stark ([EMAIL PROTECTED]) wrote:
Hm, I suppose this is expected. I always hated the idea that libraries could
introduce new symbols without an soname bump but obviously nobody's going to
be interested in an soname bump today...
!
On 10/14/07, Hannu Krosing [EMAIL PROTECTED] wrote:
Ühel kenal päeval, L, 2007-10-13 kell 17:44, kirjutas Gokulakannan
Somasundaram:
Hi,
I went through this article and it was good. Please have a look
at it.
http://www.databasecolumn.com/2007/09/one-size-fits-all.html
This
Gokulakannan Somasundaram [EMAIL PROTECTED] writes:
So Indexes with snapshots will be degrading the performance only for deletes
and only those updates, which are updating the index tuple.
Deletes never update indexes in Postgres. Increasing the size of the index
would affect vacuum, inserts,
On 10/14/07, Gokulakannan Somasundaram [EMAIL PROTECTED] wrote:
http://www.databasecolumn.com/2007/09/one-size-fits-all.html
The Vertica database(Monet is a open source version with the same
principle) makes use of the very same principle. Use more disk space,
since they are less
Hello all,
As of now, PGSQL does not support materialized views. Just wanted to confirm
the difference between the materialized view and table. Is there some operation
which can be performed only on a table and not on a materialized view or
vice-versa?
Please let me know.
Thanks in advance,
I noticed that two of the buildfarm members are failing the 8.1 branch
because they're trying to build plpython with python 2.5. To get that
to work, I think we'd need to back-patch these two fixes:
http://archives.postgresql.org/pgsql-committers/2006-11/msg00165.php
On 10/14/07, Gregory Stark [EMAIL PROTECTED] wrote:
Gokulakannan Somasundaram [EMAIL PROTECTED] writes:
So Indexes with snapshots will be degrading the performance only for
deletes
and only those updates, which are updating the index tuple.
Deletes never update indexes in Postgres.
On 10/14/07, Trevor Talbot [EMAIL PROTECTED] wrote:
On 10/14/07, Gokulakannan Somasundaram [EMAIL PROTECTED] wrote:
http://www.databasecolumn.com/2007/09/one-size-fits-all.html
The Vertica database(Monet is a open source version with the same
principle) makes use of the very same
Tom Lane wrote:
I noticed that two of the buildfarm members are failing the 8.1
branch because they're trying to build plpython with python 2.5. To
get that to work, I think we'd need to back-patch these two fixes:
http://archives.postgresql.org/pgsql-committers/2006-11/msg00165.php
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
I noticed that two of the buildfarm members are failing the 8.1
branch because they're trying to build plpython with python 2.5. To
get that to work, I think we'd need to back-patch these two fixes:
There's a gripe over here
http://archives.postgresql.org/pgsql-general/2007-10/msg00640.php
to the effect that PG should not give a message like password
authentication failure when the user is attempting to log in as a
NOLOGIN role. This surprised me because there is a specific message
for that,
On Oct 14, 2007, at 14:34 , Tom Lane wrote:
I am not entirely convinced whether we should do anything about this:
the general theory on authentication failures is that you don't say
much
about exactly why it failed, so as to not give a brute-force attacker
any info about whether he gave a
* Tom Lane ([EMAIL PROTECTED]) wrote:
We could certainly change flatfiles.c to disregard rolcanlogin, which'd
actually make the code simpler. However, that in itself wouldn't change
the behavior, unless you were to assign a password to the NOLOGIN role
which seems a fairly strange thing to
Michael Glaesemann [EMAIL PROTECTED] writes:
Would there be a difference in how this is logged and how it's
reported to the user?
Not without making all the same infrastructure changes that would be
needed to tell the user something different than now. As things stand,
the password auth code
Stephen Frost [EMAIL PROTECTED] writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
... I think what the OP wishes
is that not permitted to log in would be checked before checking
password validity, and to do that we'd have to add rolcanlogin
to the flat password file and put the check somewhere
I wrote:
Stephen Frost [EMAIL PROTECTED] writes:
I wonder if the OP was unhappy because he created a role w/ a pw and
then couldn't figure out why the user couldn't log in?
Hm, maybe. In that case just not filtering the entry out of the flat
file would be good enough.
I've confirmed the
Tom Lane wrote:
Should we just do this, or is it worth working harder?
Not worth more, IMNSHO.
cheers
andrew
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
Tom Lane wrote:
I notice though that the
second of the above-mentioned patches is only in HEAD, which is why
those same machines are giving scary-looking warnings in the 8.2
branch, eg wasp on 8.2:
The CVS log message for that says Allow PL/PythonU to compile on Python
2.5., but that is
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
I wonder if the OP was unhappy because he created a role w/ a pw and
then couldn't figure out why the user couldn't log in?
Hm, maybe. In that case just not filtering the entry out of the flat
file would be
21 matches
Mail list logo
