On Thu, May 17, 2012 at 7:26 AM, Volker Grabsch wrote:
> Hitoshi Harada schrieb:
>> On Wed, May 16, 2012 at 12:50 AM, Volker Grabsch
>> wrote:
>> > I propose the following general optimization: If all window
>> > functions are partitioned by the same first field (here: id),
>> > then any filter
On the topic on fixing pg_dump to dump in a predictable order, can
someone please update me on the current state of the problem?
I've read though pg_dump_sort.c, and note objects are first sorted in
type/name-based ordering, then topologically sorted in a way which
"minimize unnecessary rearrangem
On Wed, May 23, 2012 at 9:09 AM, Tom Lane wrote:
> Thus, not implausibly, causing the dump to fail entirely on some
> filesystems. Case sensitivity, encoding issues, and special characters
> in names (eg slashes or backslashes, depending on platform) are
> additional pain points. This does not s
On Wed, May 23, 2012 at 01:38:06AM +0400, Alexander Korotkov wrote:
> On Wed, May 23, 2012 at 1:26 AM, Bruce Momjian wrote:
>
> On Thu, May 10, 2012 at 10:22:58PM +0400, Alexander Korotkov wrote:
> > "Improve GiST box and point index performance by producing better trees
> with
>
Joel Jacobson writes:
> If the entire function identity arguments would be included in the filename,
> two dumps of the same schema in two different databases
> would be guaranteed to produce the same dump.
> This would render some very long filenames for functions with many arguments,
Thus, not
> This seems like a rather expensive solution to a problem that I'm not
> really convinced is real. Why should a client program care about the
> severity level to a greater extent than whether the message is
> ErrorResponse or NoticeResponse? In particular, I'm entirely
> unconvinced by your clai
On Wed, May 23, 2012 at 3:24 AM, Daniel Farina wrote:
> Is there a reason why the current directory format could not be
> adjusted to become more human-readable friendly for mechanical
> reasons? I realize there is a backwards compatibility problem, but it
> may be better than bloating a new opti
Tatsuo Ishii writes:
> I described the problem with possibly localized "S" filed of
> ErrorResponse(and NoticeResponse) in Frontend/Backend protocol.
> http://archives.postgresql.org/pgsql-hackers/2012-05/msg00912.php
> So I would like to propose a solution for this (for 9.3): add new
> field to
On Tue, May 22, 2012 at 4:35 PM, Stephen Frost wrote:
> * Josh Berkus (j...@agliodbs.com) wrote:
>> The local role is preferred, the same way we allow objects in the local
>> schema to overshadow objects in the global schema.
>
> I would think we'd want the exact opposite. I don't want my global
I described the problem with possibly localized "S" filed of
ErrorResponse(and NoticeResponse) in Frontend/Backend protocol.
http://archives.postgresql.org/pgsql-hackers/2012-05/msg00912.php
So I would like to propose a solution for this (for 9.3): add new
field to ErrorResponse and NoticeResponse
> That's only true if you try to satisfy both goals at once, which I'm
> not suggesting. So I believe that proposition to be false.
Oh, ok. Per your original email and follow-up arguments, you seemed to
be doing just that.
>> An alternative idea -- and one which could be deployed a lot faster -
> The issue with not allowing global spaces to overlap local ones is that
> we'd have to check every local list when creating a global account;
> that doesn't seem very easy to do. On the flip side, allowing
> duplicates between global and local would remove the need to check local
> lists when c
On Wed, May 23, 2012 at 1:26 AM, Bruce Momjian wrote:
> On Thu, May 10, 2012 at 10:22:58PM +0400, Alexander Korotkov wrote:
> > "Improve GiST box and point index performance by producing better trees
> with
> > less memory allocation overhead (Alexander Korotkov, Heikki Linnakangas,
> Kevin
> > G
On 22 May 2012 18:41, Tom Lane wrote:
> It'd be better to work on index-organized tables
My earlier analysis showed that IOTs are essentially the same thing as
block-level indexes, referred to as GITs by Heikki. (Robert referred
to these as Lossy Indexes recently, which was not the case - that
a
On Wed, May 16, 2012 at 10:49:25PM +0300, Heikki Linnakangas wrote:
> On 16.05.2012 22:38, Jeff Janes wrote:
> >For item:
> >Improve COPY performance by adding tuples to the heap in batches
> >(Heikki Linnakangas)
> >
> >I think we should point out that the batching only applies for COPY
> >into un
On Thu, May 10, 2012 at 10:22:58PM +0400, Alexander Korotkov wrote:
> "Improve GiST box and point index performance by producing better trees with
> less memory allocation overhead (Alexander Korotkov, Heikki Linnakangas, Kevin
> Grittner)"
> Is this note about following two commits?
> http://git.p
On 22 May 2012 19:01, Robert Haas wrote:
> On Tue, May 22, 2012 at 1:41 PM, Tom Lane wrote:
>> Jeff Janes writes:
>>> Now that there are index only scans, there is a use case for having a
>>> composite index which has the primary key or a unique key as the
>>> prefix column(s) but with extra col
On May22, 2012, at 22:35 , Stephen Frost wrote:
> * Josh Berkus (j...@agliodbs.com) wrote:
>> The local role is preferred, the same way we allow objects in the local
>> schema to overshadow objects in the global schema.
>
> I would think we'd want the exact opposite. I don't want my global
> 'pos
On Wed, May 16, 2012 at 05:30:27PM -0400, Bruce Momjian wrote:
>
> I will make the adjustments outlined below as soon as I can.
Done and committed.
---
>
> On Sun, May 13, 2012 at 12:37:52AM -0400, Robert Haas wrote:
> > O
On 22 May 2012 18:56, Josh Berkus wrote:
> I'm not arguing that we don't have users who would like interdatabase
> queries, especially when they port applications from MySQL or MSSQL. We
> have a lot of such users.
Lots and lots, yes.
> However, we *also* have a lot of users who
> would like t
On Tue, May 22, 2012 at 8:28 PM, Robert Haas wrote:
> Totally agreed. We're not the first people to think of this, either:
> CLOCK and GLOCK have been extensively studied and found to be almost
> as good as LRU in selecting good victim pages, but with less
> contention. That's why people are usi
* Josh Berkus (j...@agliodbs.com) wrote:
> The local role is preferred, the same way we allow objects in the local
> schema to overshadow objects in the global schema.
I would think we'd want the exact opposite. I don't want my global
'postgres' user to be overwritten by some local one that the a
On Mon, May 21, 2012 at 5:25 PM, Joel Jacobson wrote:
> If one want to reuse the splitting to files-code of the directory
> format, maybe the existing option -F d could be tweaked to output in
> both a a machine-readable format (current way), and also a
> human-friendly tree of files and content (
On Tue, May 22, 2012 at 10:56 AM, Josh Berkus wrote:
> I'm not arguing that we don't have users who would like interdatabase
> queries, especially when they port applications from MySQL or MSSQL. We
> have a lot of such users. However, we *also* have a lot of users who
> would like to treat sepa
On Tue, May 22, 2012 at 1:36 PM, Simon Riggs wrote:
> On 22 May 2012 18:24, Jeff Janes wrote:
> > Now that there are index only scans, there is a use case for having a
> > composite index which has the primary key or a unique key as the
> > prefix column(s) but with extra columns after that. Cu
On Tue, May 22, 2012 at 10:41 AM, Tom Lane wrote:
> Jeff Janes writes:
>> Now that there are index only scans, there is a use case for having a
>> composite index which has the primary key or a unique key as the
>> prefix column(s) but with extra columns after that. Currently you
>> would also n
On Fri, May 11, 2012 at 5:52 PM, Antonin Houska
wrote:
> Hello,
> following this short discussion
> http://archives.postgresql.org/message-id/4f5aa202.9020...@gmail.com
> I gave it one more try and hacked the optimizer so that function can become
> an inner relation in NL join, parametrized with v
On May 22, 2012, at 9:56 AM, Tom Lane wrote:
> It seems probably workable given that we expect the pending list to be
> of fairly constrained size. However, the commit message referenced
> upthread also muttered darkly about GIN's partial match logic not working
> in amgettuple. I do not recall
On Tue, May 22, 2012 at 1:41 PM, Tom Lane wrote:
> Jeff Janes writes:
>> Now that there are index only scans, there is a use case for having a
>> composite index which has the primary key or a unique key as the
>> prefix column(s) but with extra columns after that. Currently you
>> would also ne
> Why is it OK to allow somebody to access multiple schema in one query,
> but not multiple databases? Are you arguing that schemas are also
> broken?
Because the purpose of a database is to be a Catalog, i.e. an isolated
container, which is not the purpose of schemas. To the extent to which
we
On 22 May 2012 12:59, Tatsuo Ishii wrote:
> Also I wonder why "conflict with recovery" generates same error code
> as serialization error. For me it seems not very consistent
> choice. IMO, we should assign different error code for at least brings
> totally different effect to frontend: aborting
On Tue, May 22, 2012 at 10:43 AM, Simon Riggs wrote:
> On 22 May 2012 18:35, Josh Berkus wrote:
>>
>>> If I have a customer with 1 database per user, how do they run a query
>>> against 100 user tables? It would require 100 connections to the
>>> database. Doing that would require roughly x100 th
On Tue, May 22, 2012 at 1:27 PM, Simon Riggs wrote:
> Ack, part from the bit about OIDs no longer being unique. That might
> be an upgrade issue but its obviously something we wouldn't allow if
> we did that.
And how exactly are you going to disallow that? We currently enforce
the uniqueness of
On 22 May 2012 18:35, Josh Berkus wrote:
>
>> If I have a customer with 1 database per user, how do they run a query
>> against 100 user tables? It would require 100 connections to the
>> database. Doing that would require roughly x100 the planning time and
>> x100 the connection delay. Larger SQL
Jeff Janes writes:
> Now that there are index only scans, there is a use case for having a
> composite index which has the primary key or a unique key as the
> prefix column(s) but with extra columns after that. Currently you
> would also need another index with exactly the primary/unique key,
>
On 22 May 2012 18:24, Jeff Janes wrote:
> Now that there are index only scans, there is a use case for having a
> composite index which has the primary key or a unique key as the
> prefix column(s) but with extra columns after that. Currently you
> would also need another index with exactly the p
> If I have a customer with 1 database per user, how do they run a query
> against 100 user tables? It would require 100 connections to the
> database. Doing that would require roughly x100 the planning time and
> x100 the connection delay. Larger SQL statements pass their results
> between execut
On 22 May 2012 18:18, Josh Berkus wrote:
>
>> 1. Ability to have a Role that can only access one Database
>>
>> 2. Allow user info to be dumped with a database, to make a db
>> completely self-consistent
>>
>> 3. Allow databases to be transportable
>>
>> 4. Allow users to access tables in >1 datab
Stephen,
> Which is "preferred"
> when you do a 'grant select' or 'grant role'?
The local role is preferred, the same way we allow objects in the local
schema to overshadow objects in the global schema.
> Or do we just disallow
> overlaps between per-DB roles and global roles? If we don't all
On Tue, May 22, 2012 at 12:39 PM, Tom Lane wrote:
> Robert Haas writes:
>> If we're going to throw our current algorithm over wholesale, I'd
>> rather use some approach that has been demonstrated to work well in
>> other systems. Buffer eviction is a problem that's been around since
>> the 1970s
On 22 May 2012 14:05, Robert Haas wrote:
> On Tue, May 22, 2012 at 8:40 AM, Andrew Dunstan wrote:
>> That seems to be leaving aside the fact that we don't currently have any
>> notion of how to allow FDWs to write the foreign tables.
>>
>> What is more, isn't the postgres FDW about talking to any
Now that there are index only scans, there is a use case for having a
composite index which has the primary key or a unique key as the
prefix column(s) but with extra columns after that. Currently you
would also need another index with exactly the primary/unique key,
which seems like a waste of st
> 1. Ability to have a Role that can only access one Database
>
> 2. Allow user info to be dumped with a database, to make a db
> completely self-consistent
>
> 3. Allow databases to be transportable
>
> 4. Allow users to access tables in >1 database easily, with appropriate
> rights.
The las
On Mon, May 21, 2012 at 05:53:55PM -0700, Josh Berkus wrote:
> Hackers,
>
> There's a lot of great information in the postgres logs. While we
> eventually want to get more sophisticated about providing users with
> status and history information, for 9.3 it would be really nice to
> just offer th
On 22 May 2012 13:52, Robert Haas wrote:
> It seems pretty clear to me that making pg_upgrade responsible for
> emptying block zero is a non-starter. But I don't think that's a
> reason to throw out the design; I think it's a problem we can work
> around.
I like your design better as well *if*
Robert Haas writes:
> On Tue, May 22, 2012 at 12:28 PM, David E. Wheeler
> wrote:
>> On May 13, 2012, at 3:45 PM, Robert Haas wrote:
>>> It seems like maybe we could work around this by remembering the
>>> contents of the pending list throughout the scan. Every time we hit a
>>> TID while scanni
On Tue, May 22, 2012 at 12:28 PM, David E. Wheeler
wrote:
> On May 13, 2012, at 3:45 PM, Robert Haas wrote:
>
>> It seems like maybe we could work around this by remembering the
>> contents of the pending list throughout the scan. Every time we hit a
>> TID while scanning the main index, we check
Robert Haas writes:
> If we're going to throw our current algorithm over wholesale, I'd
> rather use some approach that has been demonstrated to work well in
> other systems. Buffer eviction is a problem that's been around since
> the 1970s, and our algorithm is just about that old.
Um, if you'r
On Mon, May 21, 2012 at 2:29 PM, Merlin Moncure wrote:
> On Mon, May 21, 2012 at 4:17 PM, Jeff Janes wrote:
>>
>> For vaguely real life, take your example of pgbench -i -s200 -F 50,
>> and I have 2Gig RAM, which seems to be the same as you do.
>>
>> With select only work load (pgbench -S -M prepa
On May 13, 2012, at 3:45 PM, Robert Haas wrote:
> It seems like maybe we could work around this by remembering the
> contents of the pending list throughout the scan. Every time we hit a
> TID while scanning the main index, we check whether we already
> returned it from the pending list; if so, w
On May22, 2012, at 18:03 , Thom Brown wrote:
> On 22 May 2012 16:57, Florian Pflug wrote:
>> On May22, 2012, at 16:09 , Tom Lane wrote:
>>> Thom Brown writes:
Conflicts would occur where localrolename matches an existing local
role name within the same database, or a global role name, b
On Tue, May 22, 2012 at 12:11 PM, Tom Lane wrote:
>> With respect to the control logic for the background writer, one idea
>> I had was to get rid of the idea that the background writer's job is
>> to write in advance of the strategy point. Instead, every time the
>> clock sweep passes over a dir
Thom Brown writes:
> On 22 May 2012 16:57, Florian Pflug wrote:
>> Maybe we could simply make all global role's OIDs even, and all local ones
>> odd, or something like that.
> Wouldn't that instantly make all previous versions of database
> clusters un-upgradable?
IIRC, pg_upgrade doesn't need
Dear Robert,
Thank you very much for the reply.
You mean when the primary which is going to switch its role to standby might
not have sent all the WAL records to the standby and If it is switched to
standby it has more WAL records than the standby which is now serves as
primary. Is it ??
It is
On May22, 2012, at 18:00 , Susanne Ebrecht wrote:
> Am 22.05.2012 17:42, schrieb Tom Lane:
>> Encoding yes, but since 9.1 we have pretty fine-grained control of
>> collation. So I think this argument is a lot weaker than it used
>> to be. It would only really apply if you have one of the corner
>
Robert Haas writes:
> On Tue, May 22, 2012 at 10:25 AM, Tom Lane wrote:
>> My own thoughts about this had pointed in the direction of getting rid
>> of the central freelist entirely, instead letting each backend run its
>> own independent clock sweep as needed.
> Hmm, that's certainly an interes
On Tue, May 22, 2012 at 12:00 PM, Susanne Ebrecht
wrote:
> Usually you want to set the collation once per language schema. E.g. schema
> russian gets Russian collation and schema British gets British collation and
> so on.
>
> CREATE SCHEMA foo LC_COLLATE bar isn't supported so you went up a level
On 22 May 2012 16:57, Florian Pflug wrote:
> On May22, 2012, at 16:09 , Tom Lane wrote:
>> Thom Brown writes:
>>> Conflicts would occur where localrolename matches an existing local
>>> role name within the same database, or a global role name, but not a
>>> local role name within another databas
Am 22.05.2012 17:42, schrieb Tom Lane:
Encoding yes, but since 9.1 we have pretty fine-grained control of
collation. So I think this argument is a lot weaker than it used
to be. It would only really apply if you have one of the corner
cases where utf8 doesn't work for you.
Yeah it got better
On Tue, May 22, 2012 at 10:25 AM, Tom Lane wrote:
>> The idea would be to have a background process (like bgwriter)
>> maintain the global LRU state and push candidate buffers onto the
>> freelist.
>
> Amit was trying to convince me of the same idea at PGCon, but I don't
> buy it. bgwriter doesn'
On May22, 2012, at 16:09 , Tom Lane wrote:
> Thom Brown writes:
>> Conflicts would occur where localrolename matches an existing local
>> role name within the same database, or a global role name, but not a
>> local role name within another database. The problem with this,
>> however, is that cre
Susanne Ebrecht writes:
> The use case in my mind for accessing more databases is when you want to
> access stuff different languages.
> You only can set encoding / LC_Collate per database not per schema.
> So for different languages you might need different databases to do
> correct sorting /
Am 22.05.2012 15:27, schrieb Albe Laurenz:
If you need different applications to routinely access each other's
tables, why not assign them to different schemas in one database?
The use case in my mind for accessing more databases is when you want to
access stuff different languages.
You only c
On Sun, May 20, 2012 at 11:28 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> I found this in contrib/sepgsql/expected/label.out:
>> SECURITY LABEL ON COLUMN t2
>> IS 'system_u:object_r:sepgsql_ro_table_t:s0'; -- be failed
>> ERROR: improper relation name (too many dotted names):
>
>> C
Robert Haas writes:
> On Tue, May 22, 2012 at 10:01 AM, Tom Lane wrote:
>> Well, keep in mind that that action is not merely there to obtain a
>> victim buffer; it is also maintaining the global LRU state (by
>> decrementing the usage counts of buffers it passes over). I don't think
>> you can c
On Mon, May 21, 2012 at 9:54 PM, Noah Misch wrote:
> On Wed, May 09, 2012 at 11:11:02PM -0400, Bruce Momjian wrote:
>> I have completed my draft of the 9.2 release notes, and committed it to
>> git.
>
> Concerning "Have psql \copy use libpq's SendQuery()", SendQuery() is a
> psql-internal interfac
* Thom Brown (t...@linux.com) wrote:
> Conflicts would occur where localrolename matches an existing local
> role name within the same database, or a global role name, but not a
> local role name within another database. The problem with this,
> however, is that creating global roles would need co
On Tue, May 22, 2012 at 9:37 AM, Thom Brown wrote:
> On 22 May 2012 14:04, Stephen Frost wrote:
>> What would the semantics of that look like though? Which is "preferred"
>> when you do a 'grant select' or 'grant role'? Or do we just disallow
>> overlaps between per-DB roles and global roles?
Thom Brown writes:
> Conflicts would occur where localrolename matches an existing local
> role name within the same database, or a global role name, but not a
> local role name within another database. The problem with this,
> however, is that creating global roles would need conflict checks
> a
On Tue, May 22, 2012 at 10:01 AM, Tom Lane wrote:
> Robert Haas writes:
>> Mind you, I think this whole area of the code needs some reengineering
>> for better performance, but I'm not sure this is the right place to
>> start. What I think is really bad is that we're forcing every
>> BufferAlloc
On Mon, May 14, 2012 at 2:24 PM, Fujii Masao wrote:
> On Fri, May 11, 2012 at 11:43 PM, Magnus Hagander wrote:
>> Should we go down the easy way and just reject connections when the flag is
>> mismatching between the client and the server (trivial to do - see the
>> attached patch)?
>
> + c
Robert Haas writes:
> Mind you, I think this whole area of the code needs some reengineering
> for better performance, but I'm not sure this is the right place to
> start. What I think is really bad is that we're forcing every
> BufferAlloc() to iterate over buffers checking whether each one is
>
On Tue, May 15, 2012 at 10:37 PM, Joachim Wieland wrote:
> If it matters, I have not promoted the master with a trigger file but
> restarted it after deleting recovery.conf.
Hmm. I think that if you do it this way, the minimum recovery point
won't be respected, which could leave you with a corru
On Wed, May 9, 2012 at 9:33 AM, Pavel Stehule wrote:
> here is patch with enhancing ErrorData structure. Now constraints
> errors and RI uses these fields
Please add this to https://commitfest.postgresql.org/action/commitfest_view/open
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
Th
On Tue, May 8, 2012 at 9:37 PM, Amit Kapila wrote:
> I have checked the code and logic according to which usage counter is
> increased when the buffer is pinned.
Fixed, thanks for the report.
> Another Doubt : Why in function BufferAlloc, it needs to hold the
> BufFreelistLock till it pin the bu
On 22 May 2012 14:04, Stephen Frost wrote:
> What would the semantics of that look like though? Which is "preferred"
> when you do a 'grant select' or 'grant role'? Or do we just disallow
> overlaps between per-DB roles and global roles? If we don't allow
> duplicates, I suspect a lot of the o
Simon Riggs wrote:
> On 21 May 2012 20:40, Stephen Frost wrote:
>
>>> This is important. I like the idea of breaking down the barriers
>>> between databases to allow it to be an option for one backend to
>>> access tables in multiple databases.
> So collecting a few requirements from various pla
On Mon, May 14, 2012 at 1:01 AM, Prakash Itnal wrote:
> Recently we faced an issue with postgres server where it is throwing error:
>
> ERROR: catalog is missing 2 attribute(s) for relid 16584
> CONTEXT: automatic analyze of table "DBRNW.public.act_wsta"
>
> I checked in the database and found t
On Mon, May 14, 2012 at 8:18 AM, chinnaobi wrote:
> I do base backup only first time on standby when it is going to be
> replicated. when ever primary goes down, standby becomes primary and
> primary becomes standby when primary comes up. When primary becomes standby
> I am restoring data from WA
On Tue, May 22, 2012 at 8:40 AM, Andrew Dunstan wrote:
> That seems to be leaving aside the fact that we don't currently have any
> notion of how to allow FDWs to write the foreign tables.
>
> What is more, isn't the postgres FDW about talking to any postgres source?
> If so, does it have special
* Simon Riggs (si...@2ndquadrant.com) wrote:
> * Ability to have a Role that can only access one Database
Alright, I'd like to think about this one specifically and solicit
feedback on the idea that we keep the existing shared role tables but
add on additional tables for per-database roles.
In th
On Tue, May 22, 2012 at 4:52 AM, Simon Riggs wrote:
> Based upon all you've said, I'd suggest that we make a new kind of
> fork, in a separate file for this, .meta. But we also optimise the VM
> and FSM in the way you suggest so that we can replace .vm and .fsm
> with just .meta in most cases. Big
On 05/22/2012 07:56 AM, Robert Haas wrote:
On Tue, May 22, 2012 at 7:35 AM, Florian Pflug wrote:
* Allow users to access tables in>1 database easily, with appropriate rights.
That one I'm very sceptical about. In the long run, I think we want better
separation of databases, not less, and thi
On Tue, May 22, 2012 at 1:50 AM, Tom Lane wrote:
> Currently, the planner keeps paths that appear to win on the grounds of
> either cheapest startup cost or cheapest total cost. It suddenly struck
> me that in many simple cases (viz, those with no LIMIT, EXISTS, cursor
> fast-start preference, et
On May22, 2012, at 13:47 , Simon Riggs wrote:
> On 22 May 2012 12:35, Florian Pflug wrote:
>>> * Allow users to access tables in >1 database easily, with appropriate
>>> rights.
>>
>> That one I'm very sceptical about. In the long run, I think we want better
>> separation of databases, not less,
On 22/05/12 13:47, Simon Riggs wrote:
On 22 May 2012 12:35, Florian Pflug wrote:
* Allow users to access tables in>1 database easily, with appropriate rights.
That one I'm very sceptical about. In the long run, I think we want better
separation of databases, not less, and this requirement carr
On 22/05/12 13:24, Simon Riggs wrote:
On 22 May 2012 12:05, José Luis Tallón wrote:
IMVHO: s/database/schema/g does resolve many of the problems that you were
referring to... and 'dblink' should solve the rest, right?
Please, feel free to point out what I am (most probably) not considering --
Hi,
ErrorResponse message from backend has some field type codes include:
S
Severity: the field contents are ERROR, FATAL, or PANIC (in an
error message), or WARNING, NOTICE, DEBUG, INFO, or LOG (in a
notice message), or a localized translation of one of
these. Always present.
C
On Tue, May 22, 2012 at 7:35 AM, Florian Pflug wrote:
>> * Allow users to access tables in >1 database easily, with appropriate
>> rights.
>
> That one I'm very sceptical about. In the long run, I think we want better
> separation of databases, not less, and this requirement carries a huge risk
>
On 22 May 2012 12:35, Florian Pflug wrote:
>> * Allow users to access tables in >1 database easily, with appropriate
>> rights.
>
> That one I'm very sceptical about. In the long run, I think we want better
> separation of databases, not less, and this requirement carries a huge risk
> of standi
On May22, 2012, at 11:46 , Simon Riggs wrote:
> * Ability to have a Role that can only access one Database
>
> * Allow user info to be dumped with a database, to make a db
> completely self-consistent
These two could be achieved by having database-local roles I think.
> * Allow databases to be t
On 22 May 2012 12:12, PostgreSQL - Hans-Jürgen Schönig
wrote:
>
> On May 22, 2012, at 9:57 AM, Simon Riggs wrote:
>
>> On 22 May 2012 06:50, Tom Lane wrote:
>>
>>> Currently, the planner keeps paths that appear to win on the grounds of
>>> either cheapest startup cost or cheapest total cost. It
> Thanks for your comments. They clarify a lot.
> But I still don't realize how can we distinguish IS_LCPRV2 and IS_LC2?
> Isn't it possible for them to produce same pg_wchar?
If LB is in 0x90 - 0x99 range, then they are LC2.
If LB is in 0xf0 - 0xff range, then they are LCPRV2.
--
Tatsuo Ishii
SRA
On 22 May 2012 12:05, José Luis Tallón wrote:
> IMVHO: s/database/schema/g does resolve many of the problems that you were
> referring to... and 'dblink' should solve the rest, right?
> Please, feel free to point out what I am (most probably) not considering --
> not experienced enough yet :)
T
On May 22, 2012, at 9:57 AM, Simon Riggs wrote:
> On 22 May 2012 06:50, Tom Lane wrote:
>
>> Currently, the planner keeps paths that appear to win on the grounds of
>> either cheapest startup cost or cheapest total cost. It suddenly struck
>> me that in many simple cases (viz, those with no LI
On 22/05/12 11:46, Simon Riggs wrote:
On 21 May 2012 20:40, Stephen Frost wrote:
This is important. I like the idea of breaking down the barriers
between databases to allow it to be an option for one backend to
access tables in multiple databases. The current mechanism doesn't
actually prevent
On Tue, May 22, 2012 at 11:50 AM, Tatsuo Ishii wrote:
>
> I think it's possible. The first characters are defined like this:
>
> #define IS_LCPRV1(c)((unsigned char)(c) == 0x9a || (unsigned char)(c)
> == 0x9b)
> #define IS_LCPRV2(c)((unsigned char)(c) == 0x9c || (unsigned char)(c)
> == 0x9
On 21 May 2012 20:40, Stephen Frost wrote:
>> This is important. I like the idea of breaking down the barriers
>> between databases to allow it to be an option for one backend to
>> access tables in multiple databases. The current mechanism doesn't
>> actually prevent looking at data from other d
On 22 May 2012 02:50, Robert Haas wrote:
>> Not very sure why a metapage is better than a catalog table.
>
> Mostly because there's no chance of the startup process accessing a
> catalog table during recovery, but it can read a metapage.
OK, sounds reasonable.
Based upon all you've said, I'd su
On 22 May 2012 06:50, Tom Lane wrote:
> Currently, the planner keeps paths that appear to win on the grounds of
> either cheapest startup cost or cheapest total cost. It suddenly struck
> me that in many simple cases (viz, those with no LIMIT, EXISTS, cursor
> fast-start preference, etc) we coul
1 - 100 of 101 matches
Mail list logo
