REVOKE does not work!

#61

Laurenz Albe ha scritto:

Quote:

Coniglio Sgabbiato <nobody (AT) nowhere (DOT) it> wrote:
The only areas in which I feel PG is lacking reliability a bit, is
datafile management (the need for (auto)vacuum/reindex in order to
preserve performance and disk space waste) and absence of load balancing
features (like Oracle RAC). If PG developers will solve that issues /
gain that goals I think PG would be fine for 100% enterprise needs.

The need for VACUUM is of course slightly annoying, but if you use
a recent version of PostgreSQL and enable autovacuum, odds are good
that you don't have to worry about it at all.
Is this good enough to "solve the issue"?

not much, autovacuum is actually a workaround. A real solution, in my
opinion, should entice changes on storage engine in order to avoid the
need of autovacuum and reindexdb, I understand that this would be very
and hard to do, so I understand the use of workarounds on this side.
BTW I found a very interesting article on this theme:
http://www.linuxinsight.com/optimize...base_size.html

Quote:

Other DBMS have different strategies to implement isolation, i.e. to keep
one user from being affected by changes another user applies concurrently.
These, however, have other problems:

Oracle uses the "undo tablespace" that contains old versions of rows.
The biggest problem with that is that after some time old rows will
automatically vanish from the undo tablespace, which can cause the
dreaded "ORA-1555: snapshot too old" error message that can suddenly
kill your transaction.

DB2 solves the problem with read locks, i.e. it blocks transactions that
want to change rows which another transaction needs unchanged. This has
an impact on concurrency.

Each of these techniques has its cost. Of course it is debatable whether
PostgreSQL has made the best choice.

I have no knowledge about storage engine internals, so I dont understand
the pros and cons, I hope some guy will find out a new way to resolve
the current issues avoiding downsides. It needs a really smart guy

Quote:

Load balancing: there are solutions, which are however not part of core
PostgreSQL. I personally have no experience with them, so I'll have to
leave judgement of these to others.

Note, however, that Oracle RAC is more than just a load balancing software.
It also provides (to some extent) transparent application failover.
It is basically several database servers running against the same
database on the same disks, and these servers have a common memory
cache, sending cached blocks from one node to the other if necessary.
It also includes its own operating system cluster software.

I doubt that anything of that dimension is likely to be written for
PostgreSQL in the near future.

Yes, I know, one of big advantages of Oracle is that in RAC they have at
the same time fault tolerance and load balancing. The use of shared
disks is at the end a SPOF, I heard something about replacing of shared
disks with use of distributed fs like OCFS2 or GFS, but it would be
another really hard thing to deal with... of course a storage engine
with mvcc without current downsides on top of distributed fs with
automatic fault tolerance and load balancing is a dream...

Quote:

I'd say that there will always be things that big commercial database
systems have that PostgreSQL won't have.

of course, they have a lot of resources more, however, since PG is a
free project, it performs really well compared to commercial systems.

Quote:

Yours,
Laurenz Albe

#62

Laurenz Albe ha scritto:

Quote:

Coniglio Sgabbiato <nobody (AT) nowhere (DOT) it> wrote:
The only areas in which I feel PG is lacking reliability a bit, is
datafile management (the need for (auto)vacuum/reindex in order to
preserve performance and disk space waste) and absence of load balancing
features (like Oracle RAC). If PG developers will solve that issues /
gain that goals I think PG would be fine for 100% enterprise needs.

The need for VACUUM is of course slightly annoying, but if you use
a recent version of PostgreSQL and enable autovacuum, odds are good
that you don't have to worry about it at all.
Is this good enough to "solve the issue"?

not much, autovacuum is actually a workaround. A real solution, in my
opinion, should entice changes on storage engine in order to avoid the
need of autovacuum and reindexdb, I understand that this would be very
and hard to do, so I understand the use of workarounds on this side.
BTW I found a very interesting article on this theme:
http://www.linuxinsight.com/optimize...base_size.html

Quote:

Other DBMS have different strategies to implement isolation, i.e. to keep
one user from being affected by changes another user applies concurrently.
These, however, have other problems:

Oracle uses the "undo tablespace" that contains old versions of rows.
The biggest problem with that is that after some time old rows will
automatically vanish from the undo tablespace, which can cause the
dreaded "ORA-1555: snapshot too old" error message that can suddenly
kill your transaction.

DB2 solves the problem with read locks, i.e. it blocks transactions that
want to change rows which another transaction needs unchanged. This has
an impact on concurrency.

Each of these techniques has its cost. Of course it is debatable whether
PostgreSQL has made the best choice.

I have no knowledge about storage engine internals, so I dont understand
the pros and cons, I hope some guy will find out a new way to resolve
the current issues avoiding downsides. It needs a really smart guy

Quote:

Load balancing: there are solutions, which are however not part of core
PostgreSQL. I personally have no experience with them, so I'll have to
leave judgement of these to others.

Note, however, that Oracle RAC is more than just a load balancing software.
It also provides (to some extent) transparent application failover.
It is basically several database servers running against the same
database on the same disks, and these servers have a common memory
cache, sending cached blocks from one node to the other if necessary.
It also includes its own operating system cluster software.

I doubt that anything of that dimension is likely to be written for
PostgreSQL in the near future.

Yes, I know, one of big advantages of Oracle is that in RAC they have at
the same time fault tolerance and load balancing. The use of shared
disks is at the end a SPOF, I heard something about replacing of shared
disks with use of distributed fs like OCFS2 or GFS, but it would be
another really hard thing to deal with... of course a storage engine
with mvcc without current downsides on top of distributed fs with
automatic fault tolerance and load balancing is a dream...

Quote:

I'd say that there will always be things that big commercial database
systems have that PostgreSQL won't have.

of course, they have a lot of resources more, however, since PG is a
free project, it performs really well compared to commercial systems.

Quote:

Yours,
Laurenz Albe

#63

Laurenz Albe ha scritto:

Quote:

Coniglio Sgabbiato <nobody (AT) nowhere (DOT) it> wrote:
The only areas in which I feel PG is lacking reliability a bit, is
datafile management (the need for (auto)vacuum/reindex in order to
preserve performance and disk space waste) and absence of load balancing
features (like Oracle RAC). If PG developers will solve that issues /
gain that goals I think PG would be fine for 100% enterprise needs.

The need for VACUUM is of course slightly annoying, but if you use
a recent version of PostgreSQL and enable autovacuum, odds are good
that you don't have to worry about it at all.
Is this good enough to "solve the issue"?

not much, autovacuum is actually a workaround. A real solution, in my
opinion, should entice changes on storage engine in order to avoid the
need of autovacuum and reindexdb, I understand that this would be very
and hard to do, so I understand the use of workarounds on this side.
BTW I found a very interesting article on this theme:
http://www.linuxinsight.com/optimize...base_size.html

Quote:

Other DBMS have different strategies to implement isolation, i.e. to keep
one user from being affected by changes another user applies concurrently.
These, however, have other problems:

Oracle uses the "undo tablespace" that contains old versions of rows.
The biggest problem with that is that after some time old rows will
automatically vanish from the undo tablespace, which can cause the
dreaded "ORA-1555: snapshot too old" error message that can suddenly
kill your transaction.

DB2 solves the problem with read locks, i.e. it blocks transactions that
want to change rows which another transaction needs unchanged. This has
an impact on concurrency.

Each of these techniques has its cost. Of course it is debatable whether
PostgreSQL has made the best choice.

I have no knowledge about storage engine internals, so I dont understand
the pros and cons, I hope some guy will find out a new way to resolve
the current issues avoiding downsides. It needs a really smart guy

Quote:

Load balancing: there are solutions, which are however not part of core
PostgreSQL. I personally have no experience with them, so I'll have to
leave judgement of these to others.

Note, however, that Oracle RAC is more than just a load balancing software.
It also provides (to some extent) transparent application failover.
It is basically several database servers running against the same
database on the same disks, and these servers have a common memory
cache, sending cached blocks from one node to the other if necessary.
It also includes its own operating system cluster software.

I doubt that anything of that dimension is likely to be written for
PostgreSQL in the near future.

Yes, I know, one of big advantages of Oracle is that in RAC they have at
the same time fault tolerance and load balancing. The use of shared
disks is at the end a SPOF, I heard something about replacing of shared
disks with use of distributed fs like OCFS2 or GFS, but it would be
another really hard thing to deal with... of course a storage engine
with mvcc without current downsides on top of distributed fs with
automatic fault tolerance and load balancing is a dream...

Quote:

I'd say that there will always be things that big commercial database
systems have that PostgreSQL won't have.

of course, they have a lot of resources more, however, since PG is a
free project, it performs really well compared to commercial systems.

Quote:

Yours,
Laurenz Albe

#64

Laurenz Albe ha scritto:

Quote:

Coniglio Sgabbiato <nobody (AT) nowhere (DOT) it> wrote:
The only areas in which I feel PG is lacking reliability a bit, is
datafile management (the need for (auto)vacuum/reindex in order to
preserve performance and disk space waste) and absence of load balancing
features (like Oracle RAC). If PG developers will solve that issues /
gain that goals I think PG would be fine for 100% enterprise needs.

The need for VACUUM is of course slightly annoying, but if you use
a recent version of PostgreSQL and enable autovacuum, odds are good
that you don't have to worry about it at all.
Is this good enough to "solve the issue"?

not much, autovacuum is actually a workaround. A real solution, in my
opinion, should entice changes on storage engine in order to avoid the
need of autovacuum and reindexdb, I understand that this would be very
and hard to do, so I understand the use of workarounds on this side.
BTW I found a very interesting article on this theme:
http://www.linuxinsight.com/optimize...base_size.html

Quote:

Other DBMS have different strategies to implement isolation, i.e. to keep
one user from being affected by changes another user applies concurrently.
These, however, have other problems:

Oracle uses the "undo tablespace" that contains old versions of rows.
The biggest problem with that is that after some time old rows will
automatically vanish from the undo tablespace, which can cause the
dreaded "ORA-1555: snapshot too old" error message that can suddenly
kill your transaction.

DB2 solves the problem with read locks, i.e. it blocks transactions that
want to change rows which another transaction needs unchanged. This has
an impact on concurrency.

Each of these techniques has its cost. Of course it is debatable whether
PostgreSQL has made the best choice.

I have no knowledge about storage engine internals, so I dont understand
the pros and cons, I hope some guy will find out a new way to resolve
the current issues avoiding downsides. It needs a really smart guy

Quote:

Load balancing: there are solutions, which are however not part of core
PostgreSQL. I personally have no experience with them, so I'll have to
leave judgement of these to others.

Note, however, that Oracle RAC is more than just a load balancing software.
It also provides (to some extent) transparent application failover.
It is basically several database servers running against the same
database on the same disks, and these servers have a common memory
cache, sending cached blocks from one node to the other if necessary.
It also includes its own operating system cluster software.

I doubt that anything of that dimension is likely to be written for
PostgreSQL in the near future.

Yes, I know, one of big advantages of Oracle is that in RAC they have at
the same time fault tolerance and load balancing. The use of shared
disks is at the end a SPOF, I heard something about replacing of shared
disks with use of distributed fs like OCFS2 or GFS, but it would be
another really hard thing to deal with... of course a storage engine
with mvcc without current downsides on top of distributed fs with
automatic fault tolerance and load balancing is a dream...

Quote:

I'd say that there will always be things that big commercial database
systems have that PostgreSQL won't have.

of course, they have a lot of resources more, however, since PG is a
free project, it performs really well compared to commercial systems.

Quote:

Yours,
Laurenz Albe

#65

Laurenz Albe ha scritto:

Quote:

Coniglio Sgabbiato <nobody (AT) nowhere (DOT) it> wrote:
The only areas in which I feel PG is lacking reliability a bit, is
datafile management (the need for (auto)vacuum/reindex in order to
preserve performance and disk space waste) and absence of load balancing
features (like Oracle RAC). If PG developers will solve that issues /
gain that goals I think PG would be fine for 100% enterprise needs.

The need for VACUUM is of course slightly annoying, but if you use
a recent version of PostgreSQL and enable autovacuum, odds are good
that you don't have to worry about it at all.
Is this good enough to "solve the issue"?

not much, autovacuum is actually a workaround. A real solution, in my
opinion, should entice changes on storage engine in order to avoid the
need of autovacuum and reindexdb, I understand that this would be very
and hard to do, so I understand the use of workarounds on this side.
BTW I found a very interesting article on this theme:
http://www.linuxinsight.com/optimize...base_size.html

Quote:

Other DBMS have different strategies to implement isolation, i.e. to keep
one user from being affected by changes another user applies concurrently.
These, however, have other problems:

Oracle uses the "undo tablespace" that contains old versions of rows.
The biggest problem with that is that after some time old rows will
automatically vanish from the undo tablespace, which can cause the
dreaded "ORA-1555: snapshot too old" error message that can suddenly
kill your transaction.

DB2 solves the problem with read locks, i.e. it blocks transactions that
want to change rows which another transaction needs unchanged. This has
an impact on concurrency.

Each of these techniques has its cost. Of course it is debatable whether
PostgreSQL has made the best choice.

I have no knowledge about storage engine internals, so I dont understand
the pros and cons, I hope some guy will find out a new way to resolve
the current issues avoiding downsides. It needs a really smart guy

Quote:

Load balancing: there are solutions, which are however not part of core
PostgreSQL. I personally have no experience with them, so I'll have to
leave judgement of these to others.

Note, however, that Oracle RAC is more than just a load balancing software.
It also provides (to some extent) transparent application failover.
It is basically several database servers running against the same
database on the same disks, and these servers have a common memory
cache, sending cached blocks from one node to the other if necessary.
It also includes its own operating system cluster software.

I doubt that anything of that dimension is likely to be written for
PostgreSQL in the near future.

Yes, I know, one of big advantages of Oracle is that in RAC they have at
the same time fault tolerance and load balancing. The use of shared
disks is at the end a SPOF, I heard something about replacing of shared
disks with use of distributed fs like OCFS2 or GFS, but it would be
another really hard thing to deal with... of course a storage engine
with mvcc without current downsides on top of distributed fs with
automatic fault tolerance and load balancing is a dream...

Quote:

I'd say that there will always be things that big commercial database
systems have that PostgreSQL won't have.

of course, they have a lot of resources more, however, since PG is a
free project, it performs really well compared to commercial systems.

Quote:

Yours,
Laurenz Albe