On Tue, Mar 2, 2010 at 10:24 PM, Gurjeet Singh wrote:
> On Tue, Mar 2, 2010 at 7:51 PM, Tom Lane wrote:
>
>> "Gurjeet Singh" writes:
>> > select relname, pg_relation_size( 'public."' || relname || '"' )/1024
>> > from (select distinct relname
>> > from (select r.relname, c.attname, c.attno
On Wed, Mar 3, 2010 at 7:29 AM, Gurjeet Singh 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 for
> preventing s
On Wed, Mar 3, 2010 at 8:37 AM, Robert Haas wrote:
> On Wed, Mar 3, 2010 at 7:29 AM, Gurjeet Singh
> 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 t
2010/3/1 Robert Haas
>
> 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:
>
> http://wiki.postgresql.org/wiki/Guide_to_repo
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" 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
> column c
2010/3/3 Oleg Serov :
>
>
> 2010/3/1 Robert Haas
>>
>> 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:
>>
>> http://wik
I'm asking to fix this =)
On Wed, Mar 3, 2010 at 9:53 PM, Robert Haas wrote:
> 2010/3/3 Oleg Serov :
> >
> >
> > 2010/3/1 Robert Haas
> >>
> >> 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
> >>
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.