"Koichi Suzuki" writes:
> This is the V3 of PITR performance improvement (readahead). The
> change of the code is as follows:
>
> 1) Now readahead is integrated into the core so that it can deal with
> sync.rep's log shipping.
> 2) posix_fadvise() call was integrated with Greg Stark's patch.
The help text for the pg_restore --clean option in the documentation is IMHO
more precise than the
text that the pg_restore binary gives:
documentation:
-c
--clean
Clean (drop) database objects before recreating them.
pg_restore binary:
-c, --clean clean (drop) schema prior to create
The last bit of performance-related hacking that seems to be needed in
the window functions patch is to fix things so that we can trim old
rows from the underlying tuplestore when they're no longer needed.
In particular I think it's critical to be able to do this for the
simple cases of lead() and
I wrote:
> Lastly, for a simple aggregate used with an OVER clause, the current
> patch seems to define the aggregate as being taken over the frame
> rather than the partition, but I cannot find anything in SQL2008 that
> lends any support to *either* definition.
Never mind that --- I found it in
"Robert Haas" writes:
> Unfortunately, if we don't want to add an explicit iswindowable flag
> (and I understand that that's ugly), then I think this is the way to
> go. It's a shame that people will have to make code changes, but
> inventing a fake AggState object just to get around this problem
According to SQL2008 section 7.11 , general rule 5, the
default definition of window framing in a window that has an ordering
clause but no framing (RANGE/ROWS) clause is that the window frame for
a given row R runs from the first row of its partition through the last
peer of R.
Section 6.10's gen
> 1. Go back to Hitoshi's plan of passing WindowAggState to the
> aggregates. This will require changing every one of the ten aggregates
> in the core distro, as well as every third-party aggregate that has
> a similar optimization; and we just have to keep our fingers crossed
> that anyone who's
On Fri, Dec 26, 2008 at 02:17:29PM -0500, Tom Lane wrote:
> So the alternatives I see are:
>
> 1. Go back to Hitoshi's plan of passing WindowAggState to the
> aggregates. This will require changing every one of the ten aggregates
> in the core distro, as well as every third-party aggregate that
"Joshua D. Drake" writes:
> I believe the goal should be correctness but why not both? Fix what we
> can and put in place a "work around" that would be removed in 8.5?
Why not both what? The driving concern here is that there might be
third-party aggregates that will dump core if invoked as wind
On Fri, 2008-12-26 at 14:17 -0500, Tom Lane wrote:
> Greg Stark writes:
> > Yeah, it seems like adding a flag like iswindowable to aggregate
> > functions is the safest option.
>
> So the alternatives I see are:
>
> 1. Go back to Hitoshi's plan of passing WindowAggState to the
> aggregates.
Greg Stark writes:
> Yeah, it seems like adding a flag like iswindowable to aggregate
> functions is the safest option.
I agree with Hitoshi-san: that's passing information in the wrong
direction. The right direction is to make it visible to the called
function which context it's being called
Hi,
I've been trying a gcc 4.4 snapshot (20081213) on buildfarm member
panda. It gets a abort during the pl-install-check part.
Here is the backtrace:
Core was generated by `postgres: build-farm pl_regression [local] SELECT '.
Program terminated with signal 6, Aborted.
[New process 3588]
#0 0x0
ITAGAKI Takahiro writes:
> I found include/storage/itempos.h is not included from any sources.
> What is it for? Should we remove it from the source tree?
Yeah, looks that way. Seems to be a hangover from one of the
Berkeley-era experiments with large objects --- I found several
references to It
>>> Emmanuel Cecchet wrote:
> There was an interesting comment by Oracle folks: Oracle does
> not provide serializability but only snapshot isolation, and still
users
> prefer to 'downgrade' to read committed for better performance. The
> Oracle guys experience seemed to indicate that there wa
Oops, I forgot to attach the patch, sorry.
Hiroshi Inoue wrote:
Hi,
I posted a patch 18 days ago but have got no responce.
Anyway I've simplified the patch by using an appropriate
gettext module.
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Magnus Hagander writes:
Thomas H.
Hi,
I posted a patch 18 days ago but have got no responce.
Anyway I've simplified the patch by using an appropriate
gettext module.
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Magnus Hagander writes:
Thomas H. wrote:
so at least that explains the "changed" behaviour. neverthe
> I updated the patch set of SE-PostgreSQL and related stuff (r1348)
>
> [1/5]
> http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1348.patch
> [2/5]
> http://sepgsql.googlecode.com/files/sepostgresql-utils-8.4devel-3-r1348.patch
> [3/5]
> http://sepgsql.googlecode.com/files/
I'm now writing v3 patch of PITR improvement, to work with sync.rep
and Hot Standby.Would like to change the thread.
2008/12/12 Pavan Deolasee :
> On Fri, Dec 12, 2008 at 9:08 AM, Koichi Suzuki wrote:
>> Hmmm, it's really like pg_readahead needs to be included in the core.
>> I don't think
18 matches
Mail list logo
