Tom Lane wrote:
Robert Haas writes:
If for some reason we needed to have tables that happened to be called
x.y.z and a.b.c accessible from a single SQL session, we could allow
that much more simply by allowing schemas to be nested. Then we could
allow arbitrary numbers of levels, not just thre
On Fri, 2011-07-08 at 12:34 -0700, Darren Duncan wrote:
> Yes, but that would just be in-memory or in temporary places external to
> every
> database. On disk internal to a database there would just be the oid. In
> fact,
> another aspect of the database model I defined is that each "database
Robert Haas writes:
> If for some reason we needed to have tables that happened to be called
> x.y.z and a.b.c accessible from a single SQL session, we could allow
> that much more simply by allowing schemas to be nested. Then we could
> allow arbitrary numbers of levels, not just three.
FWIW, I
Robert Haas wrote:
But if that's what you want, just don't put your data in different
databases in the first place. That's what schemas are for.
If for some reason we needed to have tables that happened to be called
x.y.z and a.b.c accessible from a single SQL session, we could allow
that much
On Fri, Jul 8, 2011 at 2:21 AM, Darren Duncan wrote:
> I think an even better way to support this is would be based on Postgres
> having support for directly using multiple databases within the same SQL
> session at once, as if namespaces were another level deep, the first level
> being the databa
Hello,
I was bitten by a length-truncated role name used in a script since the
truncation only raises a NOTICE. The symptom was that the some GRANTs ended up
on the wrong objects after name truncation.
Then, I experimented with tables with long names and was surprised by the
truncation behavio
Jeff Davis wrote:
On Thu, 2011-07-07 at 23:21 -0700, Darren Duncan wrote:
I think an even better way to support this is would be based on Postgres having
support for directly using multiple databases within the same SQL session at
once, as if namespaces were another level deep, the first level
My apologies if this is not the appropriate list for this, but the "novice"
list has provided no response for weeks.
I'm using Visual Studios C++ Express 2008 on Windows 7 with the "standard"
(pre-packaged) 64-bit Windows distribution of PostgreSQL v.9.0.4 and I am
having unresolved refs when
On 08/07/11 18:21, Darren Duncan wrote:
Jeff Davis wrote:
On Thu, 2011-07-07 at 20:56 -0700, Darren Duncan wrote:
When you create a temporary table, PostgreSQL needs to add rows in
pg_class, pg_attribute, and probably other system catalogs. So
there are
writes, which aren't possible in a read
I like Darren's proposal. It is elegant.
> Date: Fri, 8 Jul 2011 18:38:59 +1200
> From: gavinflo...@archidevsys.co.nz
> To: dar...@darrenduncan.net
> CC: pg...@j-davis.com; guilla...@lelarge.info; mbee...@hotmail.com;
> pgsql-general@postgresql.org; pgsql-hack...@postgresql.org
> Subject: Re:
If the query planner thinks it has the default amount of memory (128MB)
and the stats are out of date, then it will by no means be able to plan
proper execution.
I would recommend setting the effective_cache_size to an appropriate
value, running "analyze" on both tables with an appropriate stats
t
On Thu, 2011-07-07 at 23:21 -0700, Darren Duncan wrote:
> I think an even better way to support this is would be based on Postgres
> having
> support for directly using multiple databases within the same SQL session at
> once, as if namespaces were another level deep, the first level being the
On Fri, Jul 8, 2011 at 4:35 AM, Dean Rasheed wrote:
> > On Thu, 2011-07-07 at 15:34 +0200, vincent dephily wrote:
> >> Hi,
> >>
> >> I have a delete query taking 7.2G of ram (and counting) but I do not
> >> understant why so much memory is necessary. The server has 12G, and
> >> I'm afraid it'll g
On Fri, Jul 8, 2011 at 12:48 PM, Dean Rasheed wrote:
> Yes, it's the same issue that affects deferrable PK and FK
> constraints, but even non-deferrable FKs use AFTER ROW triggers that
> suffer from this problem. These triggers don't show up in a "\d" from
> psql, but they are there (try select *
On 8 July 2011 10:44, Vincent de Phily
wrote:
> On Friday 08 July 2011 10:05:47 Dean Rasheed wrote:
>> > On Thu, 2011-07-07 at 15:34 +0200, vincent dephily wrote:
>> >> Hi,
>> >>
>> >> I have a delete query taking 7.2G of ram (and counting) but I do not
>> >> understant why so much memory is neces
Op 08-07-11 10:19, David Hartveld schreef:
Op 07-07-11 18:23, Tom Lane schreef:
Karsten Hilbert writes:
On Thu, Jul 07, 2011 at 11:14:05AM -0400, Tom Lane wrote:
I'm betting Debian hasn't fixed that bug yet either and so you need
this
post-beta2 patch:
http://git.postgresql.org/gitweb/?p=post
On Friday 08 July 2011 10:31:33 French, Martin wrote:
> If the query planner thinks it has the default amount of memory (128MB)
> and the stats are out of date, then it will by no means be able to plan
> proper execution.
>
> I would recommend setting the effective_cache_size to an appropriate
> v
On Friday 08 July 2011 10:05:47 Dean Rasheed wrote:
> > On Thu, 2011-07-07 at 15:34 +0200, vincent dephily wrote:
> >> Hi,
> >>
> >> I have a delete query taking 7.2G of ram (and counting) but I do not
> >> understant why so much memory is necessary. The server has 12G, and
> >> I'm afraid it'll g
On Thursday 07 July 2011 19:54:08 French, Martin wrote:
> How up to date are the statistics for the tables in question?
>
> What value do you have for effective cache size?
>
> My guess would be that planner thinks the method it is using is right
> either for its current row number estimations, o
On Thursday 07 July 2011 22:26:45 Guillaume Lelarge wrote:
> On Thu, 2011-07-07 at 15:34 +0200, vincent dephily wrote:
> > Hi,
> >
> > I have a delete query taking 7.2G of ram (and counting) but I do not
> > understant why so much memory is necessary. The server has 12G, and
> > I'm afraid it'll g
> On Thu, 2011-07-07 at 15:34 +0200, vincent dephily wrote:
>> Hi,
>>
>> I have a delete query taking 7.2G of ram (and counting) but I do not
>> understant why so much memory is necessary. The server has 12G, and
>> I'm afraid it'll go into swap. Using postgres 8.3.14.
>>
>> I'm purging some old da
Op 07-07-11 18:23, Tom Lane schreef:
Karsten Hilbert writes:
On Thu, Jul 07, 2011 at 11:14:05AM -0400, Tom Lane wrote:
I'm betting Debian hasn't fixed that bug yet either and so you need this
post-beta2 patch:
http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=c2ba0121c73b74613
Dave Coventry wrote:
> I am getting the following error message in my Drupal install.
>
> PDOException: SQLSTATE[42501]: Insufficient privilege: 7 ERROR:
> permission denied for sequence currenttest_id_seq: INSERT INTO
> currentTest (score) VALUES (:db_insert_placeholder_0);
>
> This is a table tha
23 matches
Mail list logo
