* 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
Hey,
I was working on adding support to the new MOVE clause of the ALTER
TABLESPACE statement to pgAdmin when I noticed this issue. See this
example:
Fresh git compilation, and new database on a new cluster:
$ createdb b1
$ psql b1
psql (9.4devel)
Type "help" for help.
b1=# CREATE TABLESPACE ts
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.
Could anyone please explain the behaviour of Postgres in the cases
below? It evaluates an unused expression t.x || t.y in the first case
but doesn't do it in the second one. It's also strange that the last
explain throws an error.
postgres=# select version();
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=# \!
Hi,
I just found a weird behaviour with this statement. Here is a complete
log of my session with a 8.3(.4) server:
[EMAIL PROTECTED] mkdir /home/guillaume/ts1
[EMAIL PROTECTED] createdb db1
[EMAIL PROTECTED] LANG=C psql db1
Welcome to psql 8.3.4, the PostgreSQL interactive terminal.
Type: \cop
-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
Hi all,
I have a query that is something like this:
SELECT DISTINCT ON ( x ) x, foo(x)
FROM ...
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 o
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
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 user_id from
users_users where joindate >= '2004-03-09');
[waits and waits and waits...have to cancel]
^CCan
22 matches
Mail list logo
