Re: [HACKERS] Frequent Update Project: Design Overview ofHOTUpdates
Simon Riggs wrote: > If my assumption is badly wrong on that then perhaps HOT would not be > useful after all. If we find that the majority of UPDATEs meet the HOT > pre-conditions, then I would continue to advocate it. This is exactly my situation. All updated hit non-indexed fields, with a lot of lookups on indexes What's interesting for me is that I might want to move away from some heavy INSERT/DELETE cases to simply marking records as deleted on the application side with this. The benefit being that I retain the archive of "processed" items without having to move them, but get the advantage of good throughput for the smaller set of items being "worked on". Will be interesting to see how the design pans out. - August ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [PATCHES] WIP 2 interpreters for plperl
I wrote: [moving to -hackers] I wrote: I have made some progress with what I think is needed to have two interpreters for plperl. This is a lot harder than the pltcl case for two reasons: 1. there are no restrictions on having 2 tcl interpreters, and 2. tcl does not need to save and restore context as we have to do with perl. I think I have a conceptual siolution to these two problems, but what I have is currently segfaulting somewhat myteriously. Tracing a dynamically loaded library in a postgres backend with a debugger is less than fun, too. I am attaching what I currently have, liberally sprinkled with elog(NOTICE) calls as trace writes. With a little more perseverance I found the problem. The attached patch passes regression. But it now needs plenty of eyeballs and testing. Well, if anyone cast eyeballs over it they kept it secret from me :-( However, I have now tested the patch with the little script shown below and it seems to do the Right Thing (tm) in switching context and restoring it. So I think it can be applied to HEAD, along with an addition to the docs and a release note. Since this is a behaviour modification, do we want to apply it to the back branches? Doing so would certainly be possible, although it would be non-trivial. I have committed this to HEAD at any rate, so that we can get some buildfarm testing going. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] EAN barcode datatype
> Are you familiar with the contrib/ian module that will be in 8.2? > > -- > Michael Fuhr I develepped this code on 8.0.x version, for my work, but I can always study :) Enrico -- If Bill Gates had a penny for everytime Windows crashed,he'd be a multi-billionaire by now ...oh look, he already is [EMAIL PROTECTED] - Skype:sscotty71 http://www.linuxtime.it/enricopirozzi ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] EAN barcode datatype
On Mon, 13 Nov 2006 10:20:38 -0500 Andrew Dunstan <[EMAIL PROTECTED]> wrote: > This could be a piece of wheel reinvention. Please see > http://pgfoundry.org/projects/gtin/ I didn't know this project, I arrived later... :( Thanks Enrico -- If Bill Gates had a penny for everytime Windows crashed,he'd be a multi-billionaire by now ...oh look, he already is [EMAIL PROTECTED] - Skype:sscotty71 http://www.linuxtime.it/enricopirozzi ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] EAN barcode datatype
Enrico wrote: I'm writing a little contrib for postgresql, to handle ean barcode datatype. It contains operators and functions like ISBN datatype, and it also contains a check digit function to control right or wrong inserts. Can this code is useful for postgresql community? Now, I'm testing my code on EAN 13 barcode and when it will be ready, I will can send it to you if you want. This could be a piece of wheel reinvention. Please see http://pgfoundry.org/projects/gtin/ cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] EAN barcode datatype
On Mon, Nov 13, 2006 at 04:05:08PM +0100, Enrico wrote: > I'm writing a little contrib for postgresql, > to handle ean barcode datatype. > > It contains operators and functions like ISBN datatype, > and it also contains a check digit function to > control right or wrong inserts. > > Can this code is useful for postgresql community? Are you familiar with the contrib/ian module that will be in 8.2? -- Michael Fuhr ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] EAN barcode datatype
I'm writing a little contrib for postgresql, to handle ean barcode datatype. It contains operators and functions like ISBN datatype, and it also contains a check digit function to control right or wrong inserts. Can this code is useful for postgresql community? Now, I'm testing my code on EAN 13 barcode and when it will be ready, I will can send it to you if you want. Regards Enrico -- If Bill Gates had a penny for everytime Windows crashed,he'd be a multi-billionaire by now ...oh look, he already is [EMAIL PROTECTED] - Skype:sscotty71 http://www.linuxtime.it/enricopirozzi ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Frequent Update Project: Design Overview ofHOTUpdates
[snip] > IMHO *most* UPDATEs occur on non-indexed fields. [snip] > > If my assumption is badly wrong on that then perhaps HOT would not be > useful after all. If we find that the majority of UPDATEs meet the HOT > pre-conditions, then I would continue to advocate it. Just to confirm that the scenario is valid: our application has almost all it's updates affecting only non-indexed columns. There are a few exceptions, but the vast majority is non-indexed, and that holds to the execution frequency too, not just for the count of tables/queries. Cheers, Csaba. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Frequent Update Project: Design Overview ofHOTUpdates
On Sun, 2006-11-12 at 18:31 -0500, Robert Treat wrote: > if your not updating all of the indexes on a table (which isn't > likely) you're going to be better off with HOT Do you mean *any* rather than all? > (which isn't likely) There is no chance involved, unless the DBA adding indexes is unaware of the HOT optimization; that would be regrettable, but we would aim to make it fairly clear in the docs. IMHO *most* UPDATEs occur on non-indexed fields. I guess any analysis anybody has of the profile of UPDATEs in specific applications would be interesting, especially if those are widely available applications. My own analysis covers TPC-B, TPC-C, TPC_E and the truckin use case, plus my own experience of other applications. If my assumption is badly wrong on that then perhaps HOT would not be useful after all. If we find that the majority of UPDATEs meet the HOT pre-conditions, then I would continue to advocate it. > > > One common use case that seems problematic is the > > > indexed, frequently updated timestamp field. > > > > Not sure of the use case for that? I understand using a timestamp field > > for optimistic locking; why would you index that rather than the PK? > > > > Let's say you are doing system monitoring and you are updating last contact > times fairly regularly. Sometimes you need to look at specific systems (the > pk) and sometimes you need to query based on a time range (the indexed time > field). OK, thanks. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] adminpack and pg_catalog
Robert Treat wrote: While I don't disagree that this is an important feature, the fact that it is being designed with pgadmin specific backwards compatability (for example the functions that rename core functions) leaves me dubious as to it being a more general solution. Because of that I would be comfortable with acting on #3. The rename happened because when one of the functions was moved into core, someone decided to rename it along the way which broke compatibility with previous versions of pgAdmin. Whilst I won't in any way deny that the adminpack was specifically written for pgAdmin though, I have no problem with it being enhanced to provide non-core functionality for other admin tools in the future... in fact I would encourage it. I think it's better to support as many admin tools as possible from one contrib module, rather than for each tool to have it's own. Regards Dave. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
