On Fri, Sep 4, 2009 at 9:54 PM, Tom Lane wrote:
> Robert Haas writes:
>> In joinpath.c, match_unsorted_outer() considers materializing the
>> inner side of each nested loop if the inner path is not an index scan,
>> bitmap heap scan, tid scan, material path, function scan, CTE scan, or
>> worktabl
On Fri, Sep 4, 2009 at 9:37 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Sep 4, 2009 at 4:01 PM, Tom Lane wrote:
>>> Hmm ... reading that over again, it seems like there is a pretty
>>> obvious solution.
>
>> This doesn't seem totally horrible. But, before you go do it, do we
>> have a cl
Robert Haas writes:
> In joinpath.c, match_unsorted_outer() considers materializing the
> inner side of each nested loop if the inner path is not an index scan,
> bitmap heap scan, tid scan, material path, function scan, CTE scan, or
> worktable scan. In costsize.c, cost_nestloop() charges the st
Robert Haas writes:
> On Fri, Sep 4, 2009 at 4:01 PM, Tom Lane wrote:
>> Hmm ... reading that over again, it seems like there is a pretty
>> obvious solution.
> This doesn't seem totally horrible. But, before you go do it, do we
> have a clearly-defined plan for the rest of the project?
Rest of
On Fri, Sep 4, 2009 at 4:01 PM, Tom Lane wrote:
> I wrote:
>> Alvaro Herrera writes:
>>> No problem, just CLUSTER that table same as today.
>
>> Uh, no, that was Josh's point: you can't CLUSTER pg_class, because you
>> can't change its relfilenode. If you do, backends won't know where to
>> read
In joinpath.c, match_unsorted_outer() considers materializing the
inner side of each nested loop if the inner path is not an index scan,
bitmap heap scan, tid scan, material path, function scan, CTE scan, or
worktable scan. In costsize.c, cost_nestloop() charges the startup
cost only once if the i
Josh Berkus writes:
> On 9/4/09 2:49 PM, Tom Lane wrote:
>> Wasn't anybody paying attention?
> Apparently nobody is using it on other platforms. I know I'm not.
Some experimentation shows that systemtap is okay (modulo a small bug
https://bugzilla.redhat.com/show_bug.cgi?id=520469), but OS X's
On Fri, 2009-09-04 at 15:09 -0700, Josh Berkus wrote:
> On 9/4/09 2:49 PM, Tom Lane wrote:
>
> > Wasn't anybody paying attention?
>
> Apparently nobody is using it on other platforms.
But at least it is enabled in Fedora 11+ RPMs. Maybe there are some
users out there.
--
Devrim GÜNDÜZ, RHCE
Com
On Fri, 2009-09-04 at 15:09 -0700, Josh Berkus wrote:
> On 9/4/09 2:49 PM, Tom Lane wrote:
>
> > Wasn't anybody paying attention?
>
> Apparently nobody is using it on other platforms. I know I'm not.
That doesn't make it any less embarrassing.
Joshua D. Drake
>
>
> --
> Josh Berkus
> Pos
On 9/4/09 2:49 PM, Tom Lane wrote:
> Wasn't anybody paying attention?
Apparently nobody is using it on other platforms. I know I'm not.
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subs
On Fri, Sep 4, 2009 at 2:48 PM, Tom Lane wrote:
> Josh Berkus writes:
I have a client who uses temp tables heavily, hundreds of thousands of
creates
and drops per day. They also have long running queries. The only
thing that
keeps catalog bloat somewhat in check is vacuum
I have just discovered that this commit
http://archives.postgresql.org/pgsql-committers/2008-03/msg00316.php
which was alleged to improve our dtrace support on non-Solaris operating
systems, actually disabled it completely:
+ ifeq ($(PORTNAME), solaris)
ifeq ($(enable_dtrace), yes)
LOCALOBJS
Alvaro Herrera writes:
> The relcache need to be bootstrapped more than once, not just at
> initdb's bootstrap. (I guess you could try a breakpoint in formrdesc)
Ok so in RelationCacheInitializePhase3 we have formrdesc calls:
formrdesc("pg_class", false,
Dimitri Fontaine writes:
> Well at bootstrap time I guess noone is able to disturb the system by
> placing a concurrent CLUSTER pg_class; call. Once started, do those rels
> still need to have a special behavior?
It doesn't matter, if you fail to get past bootstrap because you
couldn't find pg_cl
Dimitri Fontaine escribió:
> Alvaro Herrera writes:
> > Dimitri Fontaine escribió:
> >> Why can't MVCC apply here? You'd have two versions of the pg_class entry
> >> that just has been CLUSTERed, and you keep the old relfilenode arround
> >> too. MVCC applies, and you teach vacuum to clean out the
Alvaro Herrera writes:
> Dimitri Fontaine escribió:
>> Why can't MVCC apply here? You'd have two versions of the pg_class entry
>> that just has been CLUSTERed, and you keep the old relfilenode arround
>> too. MVCC applies, and you teach vacuum to clean out the old file when
>> cleaning out the no
Dimitri Fontaine escribió:
> Hi,
>
> Tom Lane writes:
> > Alvaro Herrera writes:
> >> No problem, just CLUSTER that table same as today.
> >
> > Uh, no, that was Josh's point: you can't CLUSTER pg_class, because you
> > can't change its relfilenode. If you do, backends won't know where to
> > r
Hi,
Tom Lane writes:
> Alvaro Herrera writes:
>> No problem, just CLUSTER that table same as today.
>
> Uh, no, that was Josh's point: you can't CLUSTER pg_class, because you
> can't change its relfilenode. If you do, backends won't know where to
> read pg_class to find out its relfilenode.
Wh
clang developers were quick to iron out their bugs, here's Today report:
http://zlew.org/postgresql_static_check/scan-build-2009-09-04-1/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I wrote:
> Alvaro Herrera writes:
>> No problem, just CLUSTER that table same as today.
> Uh, no, that was Josh's point: you can't CLUSTER pg_class, because you
> can't change its relfilenode. If you do, backends won't know where to
> read pg_class to find out its relfilenode.
> I was wondering
Alvaro Herrera writes:
> No problem, just CLUSTER that table same as today.
Uh, no, that was Josh's point: you can't CLUSTER pg_class, because you
can't change its relfilenode. If you do, backends won't know where to
read pg_class to find out its relfilenode.
I was wondering whether maintenance
Joshua D. Drake escribió:
> On Fri, 2009-09-04 at 15:10 -0400, Tom Lane wrote:
> > Robert Haas writes:
> > > I'm confused. Are you saying that pg_class will never get bloated, so
> > > we don't need a way to debloat it? I realize that with HOT bloat is
> > > much less of a problem than it used t
On Fri, 2009-09-04 at 15:10 -0400, Tom Lane wrote:
> Robert Haas writes:
> > I'm confused. Are you saying that pg_class will never get bloated, so
> > we don't need a way to debloat it? I realize that with HOT bloat is
> > much less of a problem than it used to be, but surely it's not
> > altoge
Robert Haas writes:
> I'm confused. Are you saying that pg_class will never get bloated, so
> we don't need a way to debloat it? I realize that with HOT bloat is
> much less of a problem than it used to be, but surely it's not
> altogether impossible...
Well, it's certainly *possible*, I'm just
Tom Lane írta:
> Josh Berkus writes:
>
I have a client who uses temp tables heavily, hundreds of thousands of
creates
and drops per day. They also have long running queries. The only
thing that
keeps catalog bloat somewhat in check is vacuum full on bloated catalogs
>>>
Josh Berkus writes:
>>> I have a client who uses temp tables heavily, hundreds of thousands of
>>> creates
>>> and drops per day. They also have long running queries. The only
>>> thing that
>>> keeps catalog bloat somewhat in check is vacuum full on bloated catalogs
>>> a few times a day. With
>
All,
>>> I have a client who uses temp tables heavily, hundreds of thousands of
>>> creates
>>> and drops per day. They also have long running queries. The only
thing that
>>> keeps catalog bloat somewhat in check is vacuum full on bloated catalogs
>>> a few times a day. With
Actually, this is a
On Fri, 2009-09-04 at 09:26 -0400, Robert Haas wrote:
> Hopefully you're planning to keep that part, as it
> would be a shame if I had done it for nothing.
Not promising anything in that regard, but I appreciate your efforts to
assist. I doubt it was wasted effort in any sense. It will certainl
Oleg Bartunov wrote:
> Hi there,
>
> finally, I got time and publish some pictures from PgCon 2009
> Developer Meeting. You can find them on flickr
> http://www.flickr.com/photos/obartunov/sets/72157621993479833/
You, of all people, were using a SLR? Amazing :-) (and were hauling
around more t
On Fri, 2009-09-04 at 09:26 -0400, Robert Haas wrote:
> On Thu, Sep 3, 2009 at 5:50 PM, Simon Riggs wrote:
> >
> > On Thu, 2009-09-03 at 22:22 +0300, Heikki Linnakangas wrote:
> >> Simon Riggs wrote:
> >> > I propose we just accept that both max_connections and
> >> > max_prepared_transactions nee
On Thu, Sep 3, 2009 at 5:50 PM, Simon Riggs wrote:
>
> On Thu, 2009-09-03 at 22:22 +0300, Heikki Linnakangas wrote:
>> Simon Riggs wrote:
>> > I propose we just accept that both max_connections and
>> > max_prepared_transactions need to be set correctly for recovery to work.
>> > This will make the
Hi there,
finally, I got time and publish some pictures from PgCon 2009 Developer
Meeting. You can find them on flickr
http://www.flickr.com/photos/obartunov/sets/72157621993479833/
Regards,
Oleg
_
Oleg Bartun
Greg Stark wrote:
> On Mon, Aug 31, 2009 at 12:01 PM, Heikki
> Linnakangas wrote:
>> Hmm, perhaps we should follow what we did to chr() and ascii(): map the
>> integer to unicode code points if the database encoding is UTF-8, and
>> restrict the range to 0..127 for other multi-byte encodings.
>
>
33 matches
Mail list logo
