On Sat, Apr 10, 2010 at 11:40 PM, Greg Smith wrote:
> To be frank, that makes for a materalized view implementation of little
> value over what you can currently do as far as I'm concerned. It might be
> interesting as a prototype, but that's not necessarily going to look like
> what's needed to
Robert Haas wrote:
It's not obvious to me
that a brief full-table lock wouldn't be acceptable for an initial
implementation. Obviously it wouldn't be suitable for every use case
but since we're talking about manually refreshed views that was bound
to be true anyway.
There already is an init
Heikki Linnakangas wrote:
Your proposal basically describes
doing 1, in a limited fashion where the view is not updated
automatically, but only when the DBA runs a command to refresh it. I'm
not sure if that's useful enough on its own, writing "CREATE
MATERIALIZED VIEW ... SELECT ..." doesn't see
On Sat, Apr 10, 2010 at 10:00 AM, Jean-Gérard Pailloncy wrote:
> Hello,
>
> 1) VPD: Virtual Private Database
> I would appreciate to have a new feature in PostgreSQL.
> This is an oracle-like feature that implement "Row Level Security".
> This feature may be emulated by using VIEW/RULE but this is
On Sat, Apr 10, 2010 at 10:00 AM, Jean-Gérard Pailloncy wrote:
> 1) VPD: Virtual Private Database
> I would appreciate to have a new feature in PostgreSQL.
> This is an oracle-like feature that implement "Row Level Security".
> This feature may be emulated by using VIEW/RULE but this is very time
On Sat, Apr 10, 2010 at 02:36:41PM +0200, Boszormenyi Zoltan wrote:
> >> The above is quite reproducable, "pg_ctl stop -m immediate"
> >> "usually" inflated my serial sequence, but I had two occasions
> >> when not. The 69 -> 70 was one. The inflated increase is always 33:
> >
> > AFAIKS sequences
On Sat, Apr 10, 2010 at 2:30 PM, Jeff Davis wrote:
> On Sat, 2010-04-10 at 20:25 +0200, Yeb Havinga wrote:
>> I was thinking of a case for instance for ranges a,b,c in relations
>> A,B,C respectively, where a && b and b && c, but not a && c. Would the
>> planner consider a join path of table A an
On Fri, Apr 9, 2010 at 5:49 PM, Jeff Davis wrote:
> On Thu, 2010-04-08 at 22:29 -0400, Robert Haas wrote:
>> 1. knngist wants to use index scans to speed up queries of the form
>> SELECT ... ORDER BY(as opposed to the
>> existing machinery which only knows how to use an index for SELECT ...
>>
On Sat, 2010-04-10 at 20:25 +0200, Yeb Havinga wrote:
> I was thinking of a case for instance for ranges a,b,c in relations
> A,B,C respectively, where a && b and b && c, but not a && c. Would the
> planner consider a join path of table A and C first, then that result
> with B. After looking in
Robert Haas wrote:
On Sat, Apr 10, 2010 at 12:05 PM, Yeb Havinga wrote:
Jeff Davis wrote:
To give some context, I started a thread a while ago:
http://archives.postgresql.org/pgsql-hackers/2009-10/msg01403.php
Interesting, a join type for overlaps, which makes me think a bit
Greg Smith wrote:
> And work on MERGE support is itself blocked behind the fact that
> PostgreSQL doesn't have a good way to lock access to a key value
> that doesn't exist yet--what other databases call key range
> locking.
The bulk of the serializable implementation WIP is work to implement
On Sat, Apr 10, 2010 at 12:05 PM, Yeb Havinga wrote:
> Jeff Davis wrote:
>>
>> To give some context, I started a thread a while ago:
>>
>> http://archives.postgresql.org/pgsql-hackers/2009-10/msg01403.php
>>
>
> Interesting, a join type for overlaps, which makes me think a bit of the
> staircase j
Jeff Davis wrote:
To give some context, I started a thread a while ago:
http://archives.postgresql.org/pgsql-hackers/2009-10/msg01403.php
Interesting, a join type for overlaps, which makes me think a bit of the
staircase join for pre-post coordinates. However, does a join operator
type need
Hello,
1) VPD: Virtual Private Database
I would appreciate to have a new feature in PostgreSQL.
This is an oracle-like feature that implement "Row Level Security".
This feature may be emulated by using VIEW/RULE but this is very time
consuming and error prone.
I would appreciated to have an estim
2010/4/10 Andrew Dunstan :
> Heikki Linnakangas wrote:
>>
>> 1. Keep the materialized view up-to-date when the base tables change.
>> This can be further divided into many steps, you can begin by supporting
>> automatic updates only on very simple views with e.g a single table and
>> a where clause
Heikki Linnakangas wrote:
1. Keep the materialized view up-to-date when the base tables change.
This can be further divided into many steps, you can begin by supporting
automatic updates only on very simple views with e.g a single table and
a where clause. Then extend that to support joins, ag
On Fri, Apr 2, 2010 at 5:36 AM, Simon Riggs wrote:
> I can't duplicate this error based upon what you have said.
I fooled around with this some more and I think I know what's going
on. The error message I received was:
recovery connections cannot start because the recovery_connections
parameter
Bernd Helmle írta:
>
>
> --On 10. April 2010 09:26:41 +0200 Boszormenyi Zoltan
> wrote:
>
>> The above is quite reproducable, "pg_ctl stop -m immediate"
>> "usually" inflated my serial sequence, but I had two occasions
>> when not. The 69 -> 70 was one. The inflated increase is always 33:
>
> AFAI
On Fri, Apr 9, 2010 at 5:51 AM, Greg Stark wrote:
> Linking against as an option isn't nearly as bad since the user
> compiling it can choose whether to include the restricted feature or
> not. That's what we do with readline. However it's not nearly as
> attractive when it restricts what file for
--On 10. April 2010 09:26:41 +0200 Boszormenyi Zoltan
wrote:
The above is quite reproducable, "pg_ctl stop -m immediate"
"usually" inflated my serial sequence, but I had two occasions
when not. The 69 -> 70 was one. The inflated increase is always 33:
AFAIKS sequences are pre-logged with
Boszormenyi Zoltan írta:
> Hi,
>
> I wanted to test HS/SR and have setup two instances, one primary
> and one secondary, the secondary is obviously a copy of the primary
> while pg_start_backup() was in effect.
>
> I started up the secondary server after "SELECT pg_stop_backup()" on
> the primary.
Hi,
I wanted to test HS/SR and have setup two instances, one primary
and one secondary, the secondary is obviously a copy of the primary
while pg_start_backup() was in effect.
I started up the secondary server after "SELECT pg_stop_backup()" on
the primary. I stopped and started the primary with
On Thu, Apr 08, 2010 at 06:59:44PM +0200, Frank Jagusch wrote:
> I thought PostgreSQL is using OS specific functions for sorting (means
> Win32 functions?). This sounds not good for my request. So I ask the
> whole audience: Are others out there asking for a support for the
> alternate sort orders?
Greg Smith wrote:
> The main hidden complexity in this particular project relates to
> handling view refreshes. The non-obvious problem is that when the view
> updates, you need something like a SQL MERGE to really handle that in a
> robust way that doesn't conflict with concurrent access to queri
24 matches
Mail list logo