Simon Riggs [EMAIL PROTECTED] wrote:
Itagaki had suggested adding options to heaps also, so clearly we'd need
to add that to pg_class, rather than pg_index in that case.
Yes, I want to add options tables not only indexes. There is pg_index for
indexes, but is not pg_table for tables, so I added
On Fri, May 26, 2006 at 09:21:44PM +0100, Simon Riggs wrote:
On Fri, 2006-05-26 at 14:47 -0500, Jim C. Nasby wrote:
But the meat is:
-- work_mem --
Scale 20002
not compressed 150 805.7
On Wed, 2006-06-07 at 01:33 -0500, Jim C. Nasby wrote:
On Fri, May 26, 2006 at 09:21:44PM +0100, Simon Riggs wrote:
On Fri, 2006-05-26 at 14:47 -0500, Jim C. Nasby wrote:
But the meat is:
-- work_mem --
Scale
I encounter a situation that the server can't shutdown when a boostrap
process does ReadBuffer() but gets an read error. I guess the problem may be
like this - the boostrap process can't read at line:
smgrread(reln-rd_smgr, blockNum, (char *) bufBlock);
So it does a FATAL exit and
Koichi Suzuki wrote:
I've once proposed a patch for 64bit transaction ID, but this causes
some overhead to each tuple (XMIN and XMAX). Pgbench with 64bit
transaction ID has to pay about a couple of percent of performance.
If 64bit transaction ID is a reasonable fix, I've already posted
Koichi Suzuki wrote:
I've once proposed a patch for 64bit transaction ID, but this causes
some overhead to each tuple (XMIN and XMAX). Pgbench with 64bit
transaction ID has to pay about a couple of percent of performance. If
64bit transaction ID is a reasonable fix, I've already posted
On Tue, 2006-06-06 at 16:50 -0400, Tom Lane wrote:
I have a theory about this, and it's not pleasant at all. What I
think is that we have a Heisenberg problem here: the act of invoking
gettimeofday() actually changes what is measured.
If this theory is correct, then the entire notion of
On Wed, Jun 07, 2006 at 01:48:50PM +0200, Zdenek Kotala wrote:
Koichi Suzuki wrote:
I've once proposed a patch for 64bit transaction ID, but this causes
some overhead to each tuple (XMIN and XMAX). Pgbench with 64bit
transaction ID has to pay about a couple of percent of performance.
Travis,
We have used postgresql 7.4, 8.0, and 8.1 with DSPAM and have
never had a single problem like you are describing. In the past
on this mailing list, these sorts of issues have been caused by
hardware problems on the DB server in some cases. Good luck with
tracking it down.
Ken
On Tue,
Simon Riggs [EMAIL PROTECTED] writes:
Do we agree the idea can't go further? What next?
It still needs investigation; I'm no longer convinced that the TLB-flush
theory is correct. See rest of thread. We may well have to revert the
current patch, but I'd like to be sure we understand why.
If
On Wed, Jun 07, 2006 at 11:59:50AM +0100, Simon Riggs wrote:
On Wed, 2006-06-07 at 01:33 -0500, Jim C. Nasby wrote:
On Fri, May 26, 2006 at 09:21:44PM +0100, Simon Riggs wrote:
On Fri, 2006-05-26 at 14:47 -0500, Jim C. Nasby wrote:
But the meat is:
On Wed, 2006-06-07 at 09:35 -0500, Jim C. Nasby wrote:
Would simply changing the ORDER BY to DESC suffice for this? FWIW:
Try sorting on aid also, both ascneding and descending.
We need to try lots of tests, not just one thats chosen to show the
patch in the best light. I want this, but we
Since we are on the topic, is there a timeline/plans for openfts being
brought into core? If not, I'll continue my work on bringing it into
Gentoo Portage.
OpenFTS never, but tsearch2 is possible. But it requires enough work to do, so I
have doubt that it will be done in 8.2...
--
Teodor
On Wed, Jun 07, 2006 at 09:53:32AM -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Do we agree the idea can't go further? What next?
It still needs investigation; I'm no longer convinced that the TLB-flush
theory is correct. See rest of thread. We may well have to revert the
Qingqing Zhou [EMAIL PROTECTED] writes:
I encounter a situation that the server can't shutdown when a boostrap
process does ReadBuffer() but gets an read error.
Hm, AtProcExit_Buffers is assuming that we've done AbortTransaction,
but the WAL-replay process doesn't do that because it's not
I'd like to base on paper Generalizing Search in Generalized Search Trees by
Paul Aoki, section 4.1 Multiple Key Support
(http://www.sai.msu.su/~megera/postgres/gist/papers/csd-97-950.pdf)
Proposed algorithm (without details about nulls etc):
1) n = 1 - set column's number to first one
2)
We got a lot requests about including stemmers and ispell dictionaries for all
accessible languages into tsearch2. I understand that tsearch2 will be closer to
end user. But sources of snowball stemmers is about 800kb, each ispell
dictionaries will takes about 0.5-2M. All sizes are sized with
Martijn van Oosterhout kleptog@svana.org writes:
This would mean that we wouldn't be assuming that tuples near the end
take as long as tuples near the beginning. Except we're now dealing
will smaller numbers, so I'm worried about error accumlation.
Hm, that would explain why Hash joins
On Wed, Jun 07, 2006 at 04:11:57PM +0100, Simon Riggs wrote:
On Wed, 2006-06-07 at 09:35 -0500, Jim C. Nasby wrote:
Would simply changing the ORDER BY to DESC suffice for this? FWIW:
Try sorting on aid also, both ascneding and descending.
We need to try lots of tests, not just one thats
Hello Teodor,
I've just recently implemented an advanced full-text search function on
top of tsearch2. Searching through the manuals and websites to get the
snowball stemmer and compile my own module took me way to long. I'd
rather go fetch a cup of coffee during a 30 minute download...
I've implemented most of ADD/DROP INHERITS but it's my first significant piece
of code at this level. I would appreciate any feedback about it. In particular
I'm worried I may be on the wrong track about how some low level operations
work like memory management, syscache lookups, heap tuple
Greg Stark [EMAIL PROTECTED] writes:
Martijn van Oosterhout kleptog@svana.org writes:
This would mean that we wouldn't be assuming that tuples near the end
take as long as tuples near the beginning. Except we're now dealing
will smaller numbers, so I'm worried about error accumlation.
Hm,
Tom Lane [EMAIL PROTECTED] writes:
Nope, that is certainly not the explanation, because the hash table is
loaded in the (single) call of the Hash node at the start of the query.
It is static all through the sampled-and-not executions of the Hash Join
node, which is where our problem is.
At
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Nope, that is certainly not the explanation, because the hash table is
loaded in the (single) call of the Hash node at the start of the query.
It is static all through the sampled-and-not executions of the Hash Join
node,
Greg Stark wrote:
I can send the actual patch to psql-patches, it includes some other changes to
refactor StoreCatalogInheritance and add the syntax to gram.y. But it's still
not quite finished because of default values.
You can send what you've got, and note that it's not for application
Greg Stark [EMAIL PROTECTED] writes:
I've implemented most of ADD/DROP INHERITS but it's my first significant piece
of code at this level. I would appreciate any feedback about it.
I thought we had agreed that the semantics of ADD INHERITS would be to
reject the command if the child wasn't
800kb, each ispell dictionaries will takes about 0.5-2M. All sizes are
Sorry, withOUT compression...
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
---(end of
OpenFTS ebuild: http://bugs.gentoo.org/show_bug.cgi?id=135859
It has a USE flag for the snowball stemmer. I can take care of
packaging for Gentoo if it will free up time for you to work on other
distros.
John
PS, upstream package size isn't, and shouldn't be an issue, it should
be left to the
Ah-hah, I've sussed it. The faulty assumption can actually be stated
as: all the executions, except maybe the first, will take approximately
the same amount of time. The failing test case I've been looking at
is one where the system decides to use a batched hash join, and in
this plan type some
Tom Lane [EMAIL PROTECTED] writes:
I thought we had agreed that the semantics of ADD INHERITS would be to
reject the command if the child wasn't already suitable to be a child
of the parent. Not to modify it by adding columns or constraints or
whatever. For the proposed uses of ADD
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I thought we had agreed that the semantics of ADD INHERITS would be to
reject the command if the child wasn't already suitable to be a child
of the parent.
I didn't see any discussion like that and I find it pretty
How about those pg_ts* tables, which are specific for a database? Will they serve to the whole cluster?2006/6/7, Teodor Sigaev [EMAIL PROTECTED]
:OpenFTS never, but tsearch2 is possible. But it requires enough work to do, so I
have doubt that it will be done in 8.2...-- Rodrigo
On Wed, Jun 07, 2006 at 03:32:35PM -0400, Tom Lane wrote:
On reflection it's easy to imagine other cases where some iterations
take much longer than others in a not-very-predictable way. For
instance, a join where only a subset of the outer tuples have a match
is going to act that way. I
Martijn van Oosterhout kleptog@svana.org writes:
Anyway, as a test, if you take the approach that the measurement at
item X only applies to the tuples immediately preceding it, for the
data you posted you get a result of 0.681148 seconds. How long did that
query run that produced that data?
I
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I thought we had agreed that the semantics of ADD INHERITS would be to
reject the command if the child wasn't already suitable to be a child
of the parent.
I didn't see any
On Wed, Jun 07, 2006 at 11:34:30AM -0400, Tom Lane wrote:
timer interrupt routine does this once every few milliseconds:
One issue is that on very fast queries, you'd get absolutely no data
this way. A possible solution would be to start with an extremely short
timer interval, and ramp it up if
On Wed, Jun 07, 2006 at 11:47:45AM -0400, Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
Koichi Suzuki wrote:
I've once proposed a patch for 64bit transaction ID, but this causes
some overhead to each tuple (XMIN and XMAX).
Did you check performance on 32-bit or 64-bit systems
On Wed, 2006-06-07 at 15:32 -0400, Tom Lane wrote:
Ah-hah, I've sussed it.
so I'm
afraid this approach to sampling EXPLAIN ANALYZE is a failure.
Hmmm, I thought we already got that bit...sorry to sound negative.
I propose we revert this patch and think about an interrupt-driven
sampling
Simon Riggs [EMAIL PROTECTED] writes:
On Wed, 2006-06-07 at 15:32 -0400, Tom Lane wrote:
I propose we revert this patch and think about an interrupt-driven
sampling method instead.
I don't have much more faith in crazy scheme No.2 either. (Mine or
yours...)
Can we just have an option to
Jim C. Nasby [EMAIL PROTECTED] writes:
On Wed, Jun 07, 2006 at 11:34:30AM -0400, Tom Lane wrote:
timer interrupt routine does this once every few milliseconds:
One issue is that on very fast queries, you'd get absolutely no data
this way.
Yeah. Of course, on very fast queries you don't get
On Wed, Jun 07, 2006 at 04:04:33PM -0400, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Anyway, as a test, if you take the approach that the measurement at
item X only applies to the tuples immediately preceding it, for the
data you posted you get a result of 0.681148
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
In this situation, I think it's entirely reasonable to expect the user
to do any needed ALTER ADD COLUMN, CONSTRAINT, etc commands before
trying to attach a child table to a parent. Having the system do it
for you offers
On Wed, 2006-06-07 at 16:56 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Wed, 2006-06-07 at 15:32 -0400, Tom Lane wrote:
I propose we revert this patch and think about an interrupt-driven
sampling method instead.
I don't have much more faith in crazy scheme No.2
On Wed, Jun 07, 2006 at 03:33:54PM -0400, Greg Stark wrote:
Perhaps there should be an option when issuing the ADD INHERITS to indicate
whether you want it to create new columns or only match existing columns. That
would also give me a convenient excuse to skip all those NOTICEs about merging
Simon Riggs [EMAIL PROTECTED] writes:
On Wed, 2006-06-07 at 16:56 -0400, Tom Lane wrote:
Certainly the removal of timing
is not going to convert an intolerable EXPLAIN ANALYZE runtime into an
acceptable one;
I disagree, as have others.
The overhead seems to be on the order of a couple tens
On Wed, Jun 07, 2006 at 05:05:23PM -0400, Tom Lane wrote:
The other thing that was bothering me was whether disk I/O might be
undercounted by an interrupt-driven method. I kinda doubt that any
kernel will save up N interrupts that occur while the process is blocked
on a slow read() ... you'll
Ühel kenal päeval, K, 2006-06-07 kell 15:33, kirjutas Greg Stark:
Tom Lane [EMAIL PROTECTED] writes:
I thought we had agreed that the semantics of ADD INHERITS would be to
reject the command if the child wasn't already suitable to be a child
of the parent. Not to modify it by adding
Ühel kenal päeval, T, 2006-06-06 kell 13:53, kirjutas Christopher
Browne:
We have triggers that fire is something interesting is found on insert.
We want this thing to run for a log time.
From the numbers, you can see the PostgreSQL database is VERY loaded.
Running VACUUM may not always be
On Thu, Jun 08, 2006 at 01:30:42AM +0300, Hannu Krosing wrote:
??hel kenal p??eval, T, 2006-06-06 kell 13:53, kirjutas Christopher
Browne:
We have triggers that fire is something interesting is found on insert.
We want this thing to run for a log time.
From the numbers, you can see the
On Wed, Jun 07, 2006 at 11:47:45AM -0400, Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
Koichi Suzuki wrote:
I've once proposed a patch for 64bit transaction ID, but this causes
some overhead to each tuple (XMIN and XMAX).
Did you check performance on 32-bit or 64-bit systems
On Wed, Jun 07, 2006 at 07:07:55PM -0400, Mark Woodward wrote:
I guess what I am saying is that PostgreSQL isn't smooth, between
checkpoints and vacuum, it is near impossible to make a product that
performs consistently under high load.
Have you tuned the bgwriter and all the vacuum_cost
How does
ALTER TABLE table INHERITS ADD parent
ALTER TABLE table INHERITS DROP parent
sound?
I'll admit it doesn't read very well but it doesn't necessitate complicating
other rules in gram.y
--
greg
---(end of broadcast)---
TIP 3: Have you
Greg Stark [EMAIL PROTECTED] writes:
How does
ALTER TABLE table INHERITS ADD parent
ALTER TABLE table INHERITS DROP parent
sound?
I'll admit it doesn't read very well but it doesn't necessitate complicating
other rules in gram.y
Or alternatively if people want to keep English-like
Greg Stark said:
Greg Stark [EMAIL PROTECTED] writes:
How does
ALTER TABLE table INHERITS ADD parent
ALTER TABLE table INHERITS DROP parent
sound?
I'll admit it doesn't read very well but it doesn't necessitate
complicating other rules in gram.y
Or alternatively if people want to keep
On Saturday 04 March 2006 22:24, David Fetter wrote:
On Fri, Mar 03, 2006 at 03:35:24PM -0500, Andrew Dunstan wrote:
Bruce Momjian wrote:
Christopher Kings-Lynne wrote:
What's the consensus on this? Nobody else has chimed in, so I'm inclined
to do no more on the gounds of insufficient
Tom,
What's the consensus on this? Nobody else has chimed in, so I'm
inclined to do no more on the gounds of insufficient demand. Let's
decide before too much bitrot occurs, though.
+1 :)
+1
We were talking about this on IRC, and I feel that if we're going to do IF
EXISTS for any
On Jun 8, 2006, at 9:13 , Greg Stark wrote:
Greg Stark [EMAIL PROTECTED] writes:
How does
ALTER TABLE table INHERITS ADD parent
ALTER TABLE table INHERITS DROP parent
sound?
I'll admit it doesn't read very well but it doesn't necessitate
complicating
other rules in gram.y
Or
Andrew Dunstan [EMAIL PROTECTED] writes:
Greg Stark said:
Or alternatively if people want to keep English-like SQL style grammar:
ALTER TABLE table INHERIT parent
ALTER TABLE table NO INHERIT parent
That could work ... or maybe UNINHERIT would read better than NO INHERIT.
DISINHERIT
grzm,
ALTER TABLE table DISOWN parent?
You can't disown your parents. ;-)
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
On Thursday 01 June 2006 14:29, Robert Treat wrote:
Looking at http://www.postgresql.org/ftp/stable_snapshot/ surely we have
acheived stability at least once since 2005-11-26.. :-) Can we get that
fixed?
Bueller?
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
We got a lot requests about including stemmers and ispell dictionaries
for all accessible languages into tsearch2. I understand that tsearch2
will be closer to end user. But sources of snowball stemmers is about
800kb, each ispell dictionaries will takes about 0.5-2M. All sizes are
sized with
Perhaps we can put together the source code for all languages modules
available and provide scripts to fetch ispell data or to generate the
snowball stemmers. A debian package maintainer would have to fetch all
the data to generate all language packages. Someone else might just want
to
I thought we added something in 8.1 for doing this, but can't seem to find
anything ... where it reports how much memory is/was needed to do the sort
to the logs ...
Is that something for 8.2, that didn't get into 8.1? Or am I looking at
the wrong docs?
Thx
Marc G. Fournier
I'd be willing to help with such a project. I have experience with
tsearch2 as well as with gentoo and debian packaging. I can't help
with rpm, though.
I could help with a FreeBSD package I suppose.
Although I should probably finish up those damn GIN docs first :)
Marc G. Fournier [EMAIL PROTECTED] writes:
I thought we added something in 8.1 for doing this, but can't seem to find
anything ... where it reports how much memory is/was needed to do the sort
to the logs ...
trace_sort
regards, tom lane
Tom Lane [EMAIL PROTECTED] wrote
Do you have a test case to reproduce this problem?
According to the error message, the problem happens during reading
pg_database. I just tried to plug in this line in mdread():
+/* pretend there is an error reading pg_database */
+if
Greg Stark [EMAIL PROTECTED] writes:
While creating unreserved keywords isn't the end of the world it seems better
to stick to the vocabulary already there if possible. It makes it easier for
the user to remember how to spell commands.
+1. Don't invent new keywords (even if unreserved) when
There are roughly 420 calls of SearchSysCache() and 217 of which are just
report cache lookup failed. Shall we put the elog in the SearchSysCache
itself?
Notice that most search is on the Oid field -- which is *not* user
visible, so I think most of them can safely let SearchSysCache handle the
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
Koichi Suzuki wrote:
I've once proposed a patch for 64bit transaction ID, but this causes
some overhead to each tuple (XMIN and XMAX).
Did you check performance on 32-bit or 64-bit systems and 64-bit binary
version of PGSQL? I think
69 matches
Mail list logo
