* Guillaume Lelarge (guilla...@lelarge.info) wrote:
> Thanks for the explanation. I should have RTFM before complaining. Sorry
> for the noise :)
No prob. If people don't feel that makes sense then we can still change
it.. I don't feel particularly strongly either way, though I seem to
recall my
On Fri, 2014-05-09 at 17:16 -0400, Stephen Frost wrote:
> Guillaume,
>
> * Guillaume Lelarge (guilla...@lelarge.info) wrote:
> > Should information_schema tables be moved and not pg_catalog ones? it
> > doesn't seem consistent to me.
>
> The catalog tables are moved by changing the database's tab
Guillaume,
* Guillaume Lelarge (guilla...@lelarge.info) wrote:
> Should information_schema tables be moved and not pg_catalog ones? it
> doesn't seem consistent to me.
The catalog tables are moved by changing the database's tablespace, eg:
ALTER DATABASE ... SET TABLESPACE
That also moves any o
Vlad Arkhipov writes:
> Could anyone please explain the behaviour of Postgres in the cases
> below?
I think it has something to do with anytextcat() being mistakenly marked
as volatile, thus preventing flattening of the subquery in the cases
where you don't explicitly coerce the integer to text.
Heikki Linnakangas a écrit :
> Tom Lane wrote:
>> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>>> Yeah, seems like we need to allocate a new relfilenode in the new
>>> tablespace.
>>
>> I looked into tablecmds.c and verified that ATExecSetTableSpace doesn't
>> worry about selecting a new relfile
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Yeah, seems like we need to allocate a new relfilenode in the new
tablespace.
I looked into tablecmds.c and verified that ATExecSetTableSpace doesn't
worry about selecting a new relfilenode. I'm also noticing a number of
permissio
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Yeah, seems like we need to allocate a new relfilenode in the new
tablespace.
I looked into tablecmds.c and verified that ATExecSetTableSpace doesn't
worry about selecting a new relfilenode. I'm also noticing a number of
permissio
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Yeah, seems like we need to allocate a new relfilenode in the new
> tablespace.
I looked into tablecmds.c and verified that ATExecSetTableSpace doesn't
worry about selecting a new relfilenode. I'm also noticing a number of
permissions-type checks
Guillaume Lelarge wrote:
Tom Lane a écrit :
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
The trivial fix is to just force a checkpoint in ALTER TABLE SET
TABLESPACE. Can we do better than that? Perhaps only force a checkpoint
when we find that the file already exists.
If ALTER TABLE SET TAB
Tom Lane a écrit :
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>> The trivial fix is to just force a checkpoint in ALTER TABLE SET
>> TABLESPACE. Can we do better than that? Perhaps only force a checkpoint
>> when we find that the file already exists.
>
> If ALTER TABLE SET TABLESPACE is as
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> The trivial fix is to just force a checkpoint in ALTER TABLE SET
> TABLESPACE. Can we do better than that? Perhaps only force a checkpoint
> when we find that the file already exists.
If ALTER TABLE SET TABLESPACE is assuming that it can always us
Guillaume Lelarge wrote:
db1=# alter table t1 set tablespace ts1;
ALTER TABLE
/opt/postgresql-8.3/data/base/74472/74475
db1=# \! ls -l /home/guillaume/ts1/74472/74475
-rw--- 1 guillaume guillaume 8192 Oct 6 11:00
/home/guillaume/ts1/74472/74475
My table moved to my own tablespace.
db1=# \!
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
| Gaetano Mendola <[EMAIL PROTECTED]> writes:
|
|>my warning was due the fact that in the docs is written nowhere this
|>drawback.
|
|
| The SELECT reference page already says that the output rows are computed
| before applying ORDER BY
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> my warning was due the fact that in the docs is written nowhere this
> drawback.
The SELECT reference page already says that the output rows are computed
before applying ORDER BY or DISTINCT.
regards, tom lane
Greg Stark wrote:
Gaetano Mendola <[EMAIL PROTECTED]> writes:
now what do I see is that for each different x value
the foo is executed more than once, I guess this is because
the distinct filter out the rows after executing the query.
Is this behaviour the normal one? Shall be not documented ?
Us
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> now what do I see is that for each different x value
> the foo is executed more than once, I guess this is because
> the distinct filter out the rows after executing the query.
>
> Is this behaviour the normal one? Shall be not documented ?
Usually
Doh - I think I understand now why this is normal behavior - sorry!
Chris
Christopher Kings-Lynne wrote:
What's going on here:
usa=> select user_id from users_users where joindate >= '2004-03-09';
ERROR: column "user_id" does not exist
usa=> select * from shop_orders where user_id in (select u
17 matches
Mail list logo
