Hi,
after starting this thread
http://archives.postgresql.org/pgsql-hackers/2006-05/msg00222.php, I thought
I'd finally go for making foreign keys my own way instead of trying to patch
PostgreSQL. However, I've realized that managing foreign keys with my own
PL/SQL or C function isn't p
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
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
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) wh
"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 (r
"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
--
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 :)
--
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
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 download
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
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} PostgreS
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
"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 INHER
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 alterna
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
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 ins
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
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 Engl
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 c
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 s
> 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-bi
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
Ü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 no
Ü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 ad
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
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 co
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
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 sche
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
>> fo
On Wed, Jun 07, 2006 at 04:04:33PM -0400, Tom Lane wrote:
> Martijn van Oosterhout 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 l
"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
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 opt
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
> sampli
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 6
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
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
Martijn van Oosterhout 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 didn't save t
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
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 Hjorthttp://i
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 p
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 IN
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 so
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 p
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 broa
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 a
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
y
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 J
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.
Greg Stark <[EMAIL PROTECTED]> writes:
> Martijn van Oosterhout 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
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 creati
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...
That
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 on
Martijn van Oosterhout 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 suffer from this esp
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 c
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
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 that toda
"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
Martijn van Oosterhout writes:
> On Wed, Jun 07, 2006 at 09:53:32AM -0400, Tom Lane wrote:
>> If we do have to revert, I'd propose that we pursue the notion of
>> interrupt-driven sampling like gprof uses.
> How would that work? You could then estimate how much time was spent in
> each node, but
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 reve
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 S
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 nee
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:
> > > >
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
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, Jun
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.
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
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 pos
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 thi
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 shmem_exit
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 --
> > > Sca
70 matches
Mail list logo
