On Tue, Mar 2, 2010 at 10:24 PM, Gurjeet Singh singh.gurj...@gmail.comwrote:
On Tue, Mar 2, 2010 at 7:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Gurjeet Singh singh.gurj...@gmail.com writes:
select relname, pg_relation_size( 'public.' || relname || '' )/1024
from (select distinct relname
On Wed, Mar 3, 2010 at 7:29 AM, Gurjeet Singh singh.gurj...@gmail.com wrote:
I just realized that it is the subquery pull-up that is leading to this
problem, not predicate push-down. Sleeping over it does really help I guess
:)
So instead of the LIMIT 1000, OFFSET 0 clause is the right choice
On Wed, Mar 3, 2010 at 8:37 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Mar 3, 2010 at 7:29 AM, Gurjeet Singh singh.gurj...@gmail.com
wrote:
I just realized that it is the subquery pull-up that is leading to this
problem, not predicate push-down. Sleeping over it does really help I
2010/3/1 Robert Haas robertmh...@gmail.com
It's not obvious whether this is the same as one of the various other
problems you've complained about. If it isn't, an English description
of what you think the problem is would probably improve your odds.
See also:
The following bug has been logged online:
Bug reference: 5360
Logged by: Sergey Manakov
Email address: vial...@gmail.com
PostgreSQL version: 8.4.2
Operating system: Fedora Core 8
Description:system column named text
Details:
Hi! I'am from Russia and write English
Sergey Manakov vial...@gmail.com writes:
I have some table with column named remark and without column named
text. I wrote SQL where try to select column named text by mistake:
SELECT st.text
FROM sometable st
Where error expected, but query executed without error! Query result is one
2010/3/3 Oleg Serov sero...@gmail.com:
2010/3/1 Robert Haas robertmh...@gmail.com
It's not obvious whether this is the same as one of the various other
problems you've complained about. If it isn't, an English description
of what you think the problem is would probably improve your odds.
I'm asking to fix this =)
On Wed, Mar 3, 2010 at 9:53 PM, Robert Haas robertmh...@gmail.com wrote:
2010/3/3 Oleg Serov sero...@gmail.com:
2010/3/1 Robert Haas robertmh...@gmail.com
It's not obvious whether this is the same as one of the various other
problems you've complained
Euler Taveira de Oliveira wrote:
Tom Lane escreveu:
The window for this sort of thing isn't very large, because the first
thing pg_dump does is acquire AccessShareLock on every table it intends
to dump, and past that point it won't be possible for anyone to modify
the table's DDL. But it
