On 3/29/17 3:39 PM, David G. Johnston wrote:
That said, I'm not sure what using materialized views instead of normal
tables buys you in the first place. I could see possibly using a
materialized view as the current month's table but the historical tables
usually don't require refreshing.
My e
PostgreSQL's materialized view functionality is very useful, but one
problem is that when the view gets large, there is no way to refresh
part of it. I know that table partitioning is coming in Postgres 10,
but I haven't heard anything about ideas for partitioning / sharding of
materialized vi
I find PostgreSQL's materialized view functionality very useful, but one
problem is that when the view gets large, there is no way to refresh
part of it. I know that table partitioning is coming in Postgres 10,
but I haven't heard anything about ideas for partitioning / sharding of
materialize
On 10/23/10 11:01 AM, Craig Ringer wrote:
> Yep. As for not explicitly mentioning "lower" roles when granting a
> higher role (ie "admin" isn't also a "user") - role inheritance.
I knew about role inheritance, I just didn't know about the
pg_has_role() function for determining if a user has a rol
Hi Dmitriy,
On 10/21/10 4:21 PM, Dmitriy Igrishin wrote:
> IMO, you are trying to reinvent the wheel. Although, you may do it just for
> fun. :-)
Surely I am, but I think it made sense at the time. It doesn't make as
much sense now that I need to audit every insert/update/delete in the
database.
I have a web application with a Postgres backend. In my initial
prototype, I decided not to have a Postgres database user created for
each application user, opting instead to use my own users table.
Authentication of application users is done via PAM, so no password is
necessary in my users table
I have a PL/Perl stored procedure that's worked fine on my development
boxes but is suddenly failing when installed on a test machine. Both my
test machines and the new machine are RHEL AS5. The differences are the
test machine is 64-bit, and running Postgres 8.1.18 instead of my
development mach
I have a PL/Perl stored procedure that's worked fine on my development
boxes but is suddenly failing when installed on a test machine. Both my
test machines and the new machine are RHEL AS5. The differences are the
test machine is 64-bit, and running Postgres 8.1.18 instead of my
development mach
