-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Nov 27, 2008 at 05:15:04PM -0500, Robert Haas wrote:
> [...] Maybe
> default_statistics_target should vary with the table size? Something
> like, 0.1% of the rows to a maximum of 100... and then 0.01% of the
> rows after that to some higher
Tom Lane wrote:
> KaiGai Kohei <[EMAIL PROTECTED]> writes:
>> If my understanding is correct, the following patch can fix the matters.
>
>> !if (ExecContextForcesOids(ps, &hasoid) &&
>> !hasoid != tupdesc->tdhasoid)
>> return false;
>> --- 243,249
>> !if (Exec
Tom Lane wrote:
Scara Maccai <[EMAIL PROTECTED]> writes:
-> Index Scan using id_idx on tab1 (cost=0.00..8.27 rows=1
width=4) (actual time=0.010..0.011 rows=1 loops=1)
Index Cond: (id = 10)
-> Index Scan using out_id_idx on tab_outer (cost=0.00..8.83
rows
Hello, Simon.
On Fri, Nov 28, 2008 at 4:29 AM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2008-11-26 at 00:03 +0900, Fujii Masao wrote:
>
>> In current pg_standby, the presence of the trigger file causes
>> recovery to end whether or not the next WAL file is available.
>> Thereby, some tra
Hello,
On Tue, Nov 25, 2008 at 6:03 PM, Fujii Masao <[EMAIL PROTECTED]> wrote:
>> [2] User-configurable replication_timeout is dangerous
>> Index: backend/utils/misc/guc.c
>> + {"replication_timeout", PGC_USERSET, WAL_REPLICATION,
>>
>> You export replication_timeout as a PGC_USERSET
Hello,
I chaged the patch accoding to the comment against v3 and fixed
some bugs. Since I failed to post the patch because of the excess
of mail size, I would attach it to Wiki from this time.
http://wiki.postgresql.org/wiki/NTT%27s_Development_Projects#Patch_set
List of updates
-
Gregory Stark wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>
> > I think we need a hard limit on the number of list pages, before we can
> > consider accepting this patch. After the limit is full, the next inserter
> > can
> > flush the list, inserting the tuples in the list into the t
"Robert Haas" <[EMAIL PROTECTED]> writes:
> ANALYZE with default_statistics_target set to 10 takes 13 s. With
> 100, 92 s. With 1000, 289 s.
That is interesting. It would also be interesting to total up the time it
takes to run EXPLAIN (without ANALYZE) for a large number of queries.
I did sta
On Thu, Nov 27, 2008 at 05:15:04PM -0500, Robert Haas wrote:
> A random thought: maybe the reason I'm not seeing any benefit is
> because my tables are just too small - most contain at most a few
> thousand rows, and some are much smaller. Maybe
> default_statistics_target should vary with the tab
> Even though we all agree default_statistics_target = 10 is too low,
> proposing a 40X increase in the default value requires more evidence
> than this. In particular, the prospect of a 1600-fold increase in
> the typical cost of eqjoinsel() is a mite scary.
I just did some very quick testing of
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I think we need a hard limit on the number of list pages, before we can
> consider accepting this patch. After the limit is full, the next inserter can
> flush the list, inserting the tuples in the list into the tree, or just fall
> back to regular,
There was a small bug in the new compute_tsvector_stats function in CVS
HEAD, causing a crash with this surprisingly simple test case:
postgres=# CREATE TABLE tstest (ts tsvector);
CREATE TABLE
postgres=# INSERT INTO tstest values ('foobar');
INSERT 0 1
postgres=# ANALYZE tstest;
server closed t
Andrew Chernow napsal(a):
It would probably be useful to nail down the supported platforms, have a
list somewhere of the oldest ones: oldest solaris, hpux, irix, aix, sco,
etc...
I ran into a few --enable-thread-safety problems, Magnus fixed the
cygwin build already. hpux 10.20 and solari
Heikki Linnakangas wrote:
Here's an updated version, ...
And here it is, for real...
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
*** src/backend/access/heap/Makefile
--- src/backend/access/heap/Makefile
***
*** 12,17 subdir = src/backend/access/heap
There's a pretty fundamental issue with this patch, which is that while
buffering the inserts in the "list pages" makes the inserts fast, all
subsequent queries become slower until the tuples have been properly
inserted into the index. I'm sure it's a good tradeoff in many cases,
but there has
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
There is another problem, though, if the map is frequently probed for
pages that don't exist in the map, or the map doesn't exist at all.
Currently, the size of the map file is kept in relcache, in the
rd_vm_nblocks_cache variable.
On Tue, 2008-11-25 at 12:21 +0200, Peter Eisentraut wrote:
> Peter Eisentraut wrote:
> > Here is an implementation of distinct types,
>
> I'm withdrawing this patch from the current commit fest for further
> work. For the record, I have attached the current patch, including the
> documentation
On Tue, 2008-11-25 at 08:23 -0500, Tom Lane wrote:
> "Dave Page" <[EMAIL PROTECTED]> writes:
> > I'm in favour of including it by default (at initdb), so it's there
> > for new users to play with on any fresh install - however, there is
> > only a point to that if all the documentation examples ar
On Wed, 2008-11-26 at 00:03 +0900, Fujii Masao wrote:
> In current pg_standby, the presence of the trigger file causes
> recovery to end whether or not the next WAL file is available.
> Thereby, some transactions in the available WAL files will be
> lost. So, we cannot use this trigger file to pr
I wrote:
> > Hmm, did you apply the latest patch correctly? My build can produce
> > right results, so I don't see why it isn't fixed. Make sure the lines
> > around 2420-2430 in planner.c like:
> >/*
> > * must copyObject() to avoid args concatenatin
On Wed, 2008-11-26 at 18:02 +0530, Pavan Deolasee wrote:
> I think whats happening is that
> ResolveRecoveryConflictWithVirtualXIDs() is failing to abort
> the open transaction
>
>
> Btw, ISTM that SIGINT works only for statement cancellation. So if the
> transaction is
> ok. what about let CREATE TABLE WITH PARTITIONING to create an entry
> in a catalog indicating the key of the partition and install the
> triggers and let the trigger decide if it has the partition to insert
> the new row (making UPDATE working almost as DELETE+INSERT if it needs
> to change of p
Hi all,
I have been following that discussion very closely but it seems that we
are debating solutions without a good specification of the
problem/requirements.
I would suggest that we collect all the partitioning requirements on a
dedicated Wiki page. There might not be a one size fits it all
KaiGai Kohei <[EMAIL PROTECTED]> writes:
> If my understanding is correct, the following patch can fix the matters.
> ! if (ExecContextForcesOids(ps, &hasoid) &&
> ! hasoid != tupdesc->tdhasoid)
> return false;
> --- 243,249
> ! if (ExecContextForcesOids(ps,
On Thu, Nov 27, 2008 at 10:10 AM, Jaime Casanova
<[EMAIL PROTECTED]> wrote:
> On Thu, Nov 27, 2008 at 9:41 AM, Robert Haas <[EMAIL PROTECTED]> wrote:
>> On Thu, Nov 27, 2008 at 8:31 AM, Gregory Stark <[EMAIL PROTECTED]> wrote:
CREATE PARTITION transaction_2008_11 ON transaction WHERE record_da
On Thu, Nov 27, 2008 at 9:41 AM, Robert Haas <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 27, 2008 at 8:31 AM, Gregory Stark <[EMAIL PROTECTED]> wrote:
>>> CREATE PARTITION transaction_2008_11 ON transaction WHERE record_date
>>> BETWEEN '2008-11-01' AND '2008-11-30';
>>
>> I think the main advantage t
>> I like the idea of using table inheritance as a foundation for this
>> feature, but I think it's not going to be very useful for real-world
>> applications without cross-table indexes. Suppose for example that I
>> have five years worth of data (thus, 60 partitions) and each
>> transaction has
On Thu, Nov 27, 2008 at 8:31 AM, Gregory Stark <[EMAIL PROTECTED]> wrote:
>> CREATE PARTITION transaction_2008_11 ON transaction WHERE record_date
>> BETWEEN '2008-11-01' AND '2008-11-30';
>
> I think the main advantage to a better partitioning method would be teaching
> Postgres about the partitio
Magnus Hagander wrote:
On 25 nov 2008, at 05.00, Tom Lane <[EMAIL PROTECTED]> wrote:
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
If that's true then this code is presently broken for *every* locale
under Windows, not only Japanese.
Maybe there are a few languages/countires wh
On Thu, Nov 27, 2008 at 8:07 AM, Robert Haas <[EMAIL PROTECTED]> wrote:
>
> The semantics of PARTITION ON () are unclear to me. I was
> thinking maybe it would make sense to do something like:
>
> CREATE PARTITION ON WHERE
>
At first look seems nice but s Gregory said the ideal would be to
ide
Hi,
>
> > The status has always being WIP, because what has not happened is that we
> > have not had consensus on whether this is a logical first baby step ahead
> > with partitioning. I haven't seen core members commenting on whether
> trying
> > to aggregate the current set of manual operations
Magnus Hagander wrote:
On 27 nov 2008, at 13.00, Alvaro Herrera <[EMAIL PROTECTED]>
wrote:
Peter Eisentraut wrote:
Magnus Hagander wrote:
Can someone remind me why we have --enable-thread-safety? As opposed to
it being default and having --disable-thread-safety.
I don't have any numbers or
--On Donnerstag, August 07, 2008 08:03:52 -0400 Robert Haas
<[EMAIL PROTECTED]> wrote:
Here's a patch that allows CREATE OR REPLACE VIEW to add new columns
to an existing view.
Any feedback would be appreciated, especially if it meant that I could
fix any problems before the next commitfest.
"Robert Haas" <[EMAIL PROTECTED]> writes:
> CREATE PARTITION transaction_2008_11 ON transaction WHERE record_date
> BETWEEN '2008-11-01' AND '2008-11-30';
I think the main advantage to a better partitioning method would be teaching
Postgres about the partition key. Instead of a collection of diff
On 27 nov 2008, at 13.00, Alvaro Herrera <[EMAIL PROTECTED]>
wrote:
Peter Eisentraut wrote:
Magnus Hagander wrote:
Can someone remind me why we have --enable-thread-safety? As
opposed to
it being default and having --disable-thread-safety.
I don't have any numbers or a roster to support
On Thu, Nov 27, 2008 at 7:04 AM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> Nikhil Sontakke escribió:
>
>> The status has always being WIP, because what has not happened is that we
>> have not had consensus on whether this is a logical first baby step ahead
>> with partitioning. I haven't seen cor
Alvaro Herrera wrote:
Well, duh, the checking is actually pretty simple. We just try to
connect with psql to the candidate port number before starting our own
postmaster and see if anyone is already there.
But what if something else is using the port? I think you could attempt
a bare conne
maosen.zhang wrote:
I begin an “pg external table” in pgfoundry
(http://pgfoundry.org/projects/pgexternaltable/ ), you can find the doc
(brief and detail design)from that URL.
I am newbie to postgresql, and this code still have many defects and low
efficiency. I am very happy to get advice f
Nikhil Sontakke escribió:
> The status has always being WIP, because what has not happened is that we
> have not had consensus on whether this is a logical first baby step ahead
> with partitioning. I haven't seen core members commenting on whether trying
> to aggregate the current set of manual o
Peter Eisentraut wrote:
> Magnus Hagander wrote:
>> Can someone remind me why we have --enable-thread-safety? As opposed to
>> it being default and having --disable-thread-safety.
>
> I don't have any numbers or a roster to support this, but I suppose that
> thread-safety is not supported on som
Peter Eisentraut wrote:
> Peter Eisentraut wrote:
>> Alvaro Herrera wrote:
>>> Is it possible to make it retry in case the chosen port is busy? I
>>> guess a simple check should suffice, ignoring the obvious race condition
>>> that someone uses the port after you checked it was OK.
>>
>> Well, the
Robert Haas napsal(a):
1. htup and bufpage API clean up
2. HeapTuple version extension + code cleanup
3. In-place online upgrade
4. Extending pg_class info + more flexible TOAST chunk size
big thanks for your review. I think #1 is still partially valid, because it
contains general cleanups, but
Gregory Stark wrote:
There is documentation
http://www.postgresql.org/docs/8.3/static/explicit-locking.html
However I found it very confusing when I was first learning. It's not really
the documentation's fault either, there are just a lot of different lock
levels with a lot of different combin
Peter Eisentraut wrote:
Alvaro Herrera wrote:
Is it possible to make it retry in case the chosen port is busy? I
guess a simple check should suffice, ignoring the obvious race condition
that someone uses the port after you checked it was OK.
Well, the whole point of this exercise was to avoid
Magnus Hagander wrote:
Can someone remind me why we have --enable-thread-safety? As opposed to
it being default and having --disable-thread-safety.
I don't have any numbers or a roster to support this, but I suppose that
thread-safety is not supported on some platforms. So either we'd have
t
Hi,
> i review it on nov 6, and there were open questions by me and by
> > Emmanuel none of those has been answered:
> > http://archives.postgresql.org/pgsql-hackers/2008-11/msg00362.php
>
> Hmm, there's only one actual question in that email, which is a
> request for ideas about PL/pgsql vs. C.
On Wed, 2008-11-26 at 23:17 -0500, Robert Haas wrote:
> > Though it is a somewhat separate problem from current patch I'd like to
> > do something about it before having it all committed, as the fix must
> > touch the very same places than this patch.
> >
> > I think it takes two-tree days to figur
test
maosen
Hi all:
I begin an "pg external table" in pgfoundry
(http://pgfoundry.org/projects/pgexternaltable/ ), you can find the doc
(brief and detail design)from that URL.
I am newbie to postgresql, and this code still have many defects and low
efficiency. I am very happy to get advice from you!
Thank
49 matches
Mail list logo