Here's an updated version of my "generic options for explain" patch.
http://archives.postgresql.org/message-id/603c8f070905231747j2e099c23hef8eafbf26682...@mail.gmail.com
This is rebased to CVS HEAD, post pgindent. Also, I've made a few
changes to the syntax. Previously, I suggested this syntax
OK, here it is again. Changes are the same as the previous version,
but this one should apply cleanly after today's pgindent run.
http://archives.postgresql.org/message-id/603c8f070906051803nd4a9e3ekb72bcc379ad73...@mail.gmail.com
(Rebasing this wasn't too bad, but I have to say that one thing t
Tom Lane wrote:
> "Kevin Grittner" writes:
>> So it would be premature to submit a patch for changing this
behavior?
>
> No, I don't think so, since there's no apparent need for a control
knob.
> You just change the limit that's applied during the last phase of
> toast_insert_or_update.
Pro
Tom Lane wrote:
> I just started reading the pg_migrator source code, and I notice that
> we still didn't get AlterTableCreateToastTable's API right for
> pg_migrator's usage. It needs to be exposing an option to force
> a particular OID for the toast table. The way pg_migrator is handling
> that
Tom Lane wrote:
> Andrew Dunstan writes:
> > Bruce Momjian wrote:
> > + # Structure/union pointers in function prototypes and definitions have an
> > extra
> > + # space after the asterisk:
> > + #
> > + # void x(struct xxc * a);
>
> > I know we should not be driven by our tools, but is there a
Alvaro Herrera wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
+ #
+ # Structure/union pointers in function prototypes and definitions have an
extra
+ # space after the asterisk:
+ #
+ # void x(struct xxc * a);
I know we should not be driven by our tools, but is there a case for a
Andrew Dunstan writes:
> Bruce Momjian wrote:
> + # Structure/union pointers in function prototypes and definitions have an
> extra
> + # space after the asterisk:
> + #
> + # void x(struct xxc * a);
> I know we should not be driven by our tools, but is there a case for a
> coding standard th
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
>
> + #
> + # Structure/union pointers in function prototypes and definitions have an
> extra
> + # space after the asterisk:
> + #
> + # void x(struct xxc * a);
>
>
> I know we should not be driven by our tools, but is there a case for a
> codi
Bruce Momjian wrote:
+ #
+ # Structure/union pointers in function prototypes and definitions have an
extra
+ # space after the asterisk:
+ #
+ # void x(struct xxc * a);
I know we should not be driven by our tools, but is there a case for a
coding standard that requires use of a typedef
Tom Lane wrote:
> I just started reading the pg_migrator source code, and I notice that
> we still didn't get AlterTableCreateToastTable's API right for
> pg_migrator's usage. It needs to be exposing an option to force
> a particular OID for the toast table. The way pg_migrator is handling
> that
"Kevin Grittner" writes:
>>> It seems to me that MAIN might be a more useful option if it was
>>> more aggressive about avoiding out-of-line storage; perhaps only if
>>> the row doesn't fit by itself on a single page?
>>
>> Yeah I think we're on the same page there.
> Cool.
>> We've been talk
Greg Stark wrote:
> On Thu, Jun 11, 2009 at 5:12 PM, Kevin
> Grittner wrote:
>>
>> MAIN allows compression but discourages out-of-line storage.
>> (Out-of-line storage will be performed only if the row is still too
>> big after compression and out-of-line storage of EXTENDED and
>> EXTERNAL colum
On Thu, Jun 11, 2009 at 5:12 PM, Kevin
Grittner wrote:
>
> MAIN allows compression but discourages out-of-line storage.
> (Out-of-line storage will be performed only if the row is still too
> big after compression and out-of-line storage of EXTENDED and
> EXTERNAL columns.)
I had the impression th
"Kevin Grittner" writes:
> It seems to me that MAIN might be a more useful option if it was more
> aggressive about avoiding out-of-line storage; perhaps only if the row
> doesn't fit by itself on a single page? Does anyone else think so?
I think that's exactly what Greg Stark was proposing. Mi
I just started reading the pg_migrator source code, and I notice that
we still didn't get AlterTableCreateToastTable's API right for
pg_migrator's usage. It needs to be exposing an option to force
a particular OID for the toast table. The way pg_migrator is handling
that now is both ugly and unsa
Tom,
Seems a bit pointless unless we have a better example to offer instead.
intarray maybe. Or just document which logic is wrong so people don't
copy that. We owe it to people to warn them.
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list
On Thu, Jun 11, 2009 at 2:13 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> I confirmed the aix problem on 4.3.3. Installed the patches and
>> updated postgres 8.4b2 removing the aix hack. Server starts fine:
>
>> $ LOG: could not bind IPv6 socket: Addr family not supported by protocol
>> HINT:
Merlin Moncure writes:
> I confirmed the aix problem on 4.3.3. Installed the patches and
> updated postgres 8.4b2 removing the aix hack. Server starts fine:
> $ LOG: could not bind IPv6 socket: Addr family not supported by protocol
> HINT: Is another postmaster already running on port 5432? If
Hitoshi Harada writes:
> 2009/6/11 J. Greg Davidson :
>> -- BREAKS IN PG 8.4 beta1 & beta2, vis:
>> -- ERROR: 0A000: set-valued function called in context that cannot
>> accept a set
> I am not completely sure but rsi->expectedDesc check seems not needed
> as before. All regression tests p
Alvaro Herrera wrote:
BTW if we had an "official" typedef list that could be used for the
length of a whole major release, we could run pgindent on a regular
basis (say fortnightly or monthly); patch submitters would just need to
run it on their own trees to avoid merge conflicts.
(Hmm, but I'
Tom Lane wrote:
> "Kevin Grittner" writes:
>> So what *is* the difference between EXTENDED and MAIN?
>
> EXTENDED columns get pushed out first. So if you have some EXTENDED
> columns and some MAIN columns, it'll give preference to keeping the
> MAIN columns in-line. In the OP's case there's o
"Kevin Grittner" writes:
> Greg Stark wrote:
>> tuptoaster.c only has one definition of "small enough" which is
>> whether the record is smaller than TOAST_TUPLE_THRESHOLD.
> So what *is* the difference between EXTENDED and MAIN?
EXTENDED columns get pushed out first. So if you have some EXT
On Jun 10, 2009, at 11:06 PM, KaiGai Kohei wrote:
The SE-PostgreSQL patches are updated as follows:
Kohei-San,
I've no idea whether SE-PostgreSQL will ever make it into the core
distribution, and have no way to really determine whether or not it's
a good idea, but I did want to say:
I a
Greg Stark wrote:
> tuptoaster.c only has one definition of "small enough" which is
> whether the record is smaller than TOAST_TUPLE_THRESHOLD.
So what *is* the difference between EXTENDED and MAIN?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Thu, Jun 11, 2009 at 4:24 PM, Kevin
Grittner wrote:
>
> I thought that's the behavior of EXTENDED. The fine manual says "MAIN
> allows compression but not out-of-line storage. (Actually, out-of-line
> storage will still be performed for such columns, but only as a last
> resort when there is no
Tom Lane wrote:
"Kevin Grittner" writes:
>> Why not use "ALTER COLUMN SET STORAGE MAIN", to allow compression
>> but avoid external storage?
>
> That only discourages pushing a particular column out; it will still
> do so if the row exceeds TOAST_TUPLE_THRESHOLD after compression.
I thought t
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>> Do we have any TODO items concerning pgindent at this point? Y
>>
>
> Yes, we will make the buildfarm and standalone find-typedefs run from a
> common pieces of code so they are always in sync.
BTW if we had an "official" typedef list that could
Tom Lane wrote:
Do we have any TODO items concerning pgindent at this point? Y
Yes, we will make the buildfarm and standalone find-typedefs run from a
common pieces of code so they are always in sync.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On Thu, Jun 11, 2009 at 4:03 PM, Shadar wrote:
>
>>>- I don't believe we have any record over 8K. So the 2nd method is best?
>
> When should I drop the TOAST table, before or after my DB is populated? I.e.
> Postgres will then move the TOASTED data inside my table?
No it won't. Any data in the toa
"Kevin Grittner" writes:
> Greg Stark wrote:
>> You could use "ALTER COLUMN SET STORAGE PLAIN" to disable toasting on
>> that column entirely. This will disable compression as well though.
> Why not use "ALTER COLUMN SET STORAGE MAIN", to allow compression but
> avoid external storage?
That on
Greg Stark-5 wrote:
>
> On Thu, Jun 11, 2009 at 3:32 PM, Shadar wrote:
>>
>> I notice that one of my tables gets TOASTed, about 40% of it. I read
>> about
>> TOAST and understand the general motivation (get faster access to the
>> *other* columns). But in my case the big column (~2.5KB fixed wi
Bruce Momjian writes:
> OK, pgindent run with updated list and applied to CVS HEAD. I eyeballed
> the patch and it looked clean, and it tested successfully. Thanks.
Do we have any TODO items concerning pgindent at this point? You had
mentioned wanting to research its behavior for 'struct foo v
Greg Stark wrote:
> You could use "ALTER COLUMN SET STORAGE PLAIN" to disable toasting
on
> that column entirely. This will disable compression as well though.
If
> any record doesn't fit in an 8kB block you'll get an error.
>
> Alternately you could leave the column alone but drop the toast
ta
On Thu, Jun 11, 2009 at 3:32 PM, Shadar wrote:
>
> I notice that one of my tables gets TOASTed, about 40% of it. I read about
> TOAST and understand the general motivation (get faster access to the
> *other* columns). But in my case the big column (~2.5KB fixed width) is a
> list (array) of values
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> > Andrew Dunstan wrote:
> >
> >> Bruce Momjian wrote:
> >>
> The consolidated list comes from Windows(mingw) and Linux. My Cygwin
> run broke for some reason, and 'objdump --stabs' doesn't seem to do what
> we need on FB
I notice that one of my tables gets TOASTed, about 40% of it. I read about
TOAST and understand the general motivation (get faster access to the
*other* columns). But in my case the big column (~2.5KB fixed width) is a
list (array) of values (not text) and the usage pattern is that I always
access
Merlin Moncure writes:
> On Thu, Jun 11, 2009 at 9:50 AM, Tom Lane wrote:
>> Where are we on this?
> waiting on a patch? Albe? (or should I do it myself?)
I thought the proposed patch was just "remove the special case for AIX
in src/backend/libpq/ip.c".
regards, tom lan
On Thu, Jun 11, 2009 at 9:50 AM, Tom Lane wrote:
> Merlin Moncure writes:
>>> "Albe Laurenz" writes:
Maybe it would be good enough to state that AIX is only supported with
certain fixpacks installed? And do without all the AIX hacks?
>
>> my take is to go with Albe's solution. I'm down
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
The consolidated list comes from Windows(mingw) and Linux. My Cygwin
run broke for some reason, and 'objdump --stabs' doesn't seem to do what
we need on FBSD, so the output there was empty. If someone knows how to
get
Merlin Moncure writes:
>> "Albe Laurenz" writes:
>>> Maybe it would be good enough to state that AIX is only supported with
>>> certain fixpacks installed? And do without all the AIX hacks?
> my take is to go with Albe's solution. I'm downloading the cumulative
> fixpack for 4.3.3:
> http://ww
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> >> The consolidated list comes from Windows(mingw) and Linux. My Cygwin
> >> run broke for some reason, and 'objdump --stabs' doesn't seem to do what
> >> we need on FBSD, so the output there was empty. If someone knows how to
> >> get the ty
2009/6/11 J. Greg Davidson :
> Dear PostgreSQL Hackers,
>
> Through PostgreSQL 8.3, both of the following functions worked, using
> generate_series(array_lower($1, 1), array_upper($1, 1)) i
> instead of generate_subscripts($1, 1).
>
> With PostgreSQL 8.4, both are accepted, but only the second one
42 matches
Mail list logo
