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
test
maosen
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 figure out
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. I
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
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
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
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 whole point of
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 some
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
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
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 core members
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
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 different
--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.
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
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
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
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 together
On Thu, Nov 27, 2008 at 8:07 AM, Robert Haas [EMAIL PROTECTED] wrote:
The semantics of PARTITION ON (expr) are unclear to me. I was
thinking maybe it would make sense to do something like:
CREATE PARTITION name ON table WHERE expr
At first look seems nice but s Gregory said the ideal would
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 where
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 partition key.
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 a unique
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 to a better
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_date
BETWEEN
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, hasoid))
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
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
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 in
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 concatenating
with
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
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 are based on
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 work
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.
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
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
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
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
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,
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 a
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 table
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 start
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 tree, or
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
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 variable,
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 transactions
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=1
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
-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
49 matches
Mail list logo
