Re: [PATCHES] New features for pgbench

ry, but I do not understand the above. If I read it correctly, are you suggesting that the same database with a prior pgbench run be used for further pgbench runs? How is it useful? How can one guarantee consistency of observed tps values with this in place? Regards, Nikhils -- EnterpriseDB

Re: [PATCHES] New features for pgbench

the run is I/O intensive enough etc. IMHO, as long as the same environment holds true for both the source base runs, we should not see unexplained variations as per the reasons you have mentioned in the observed TPS values. Regards, Nikhils -- EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] Recalculating OldestXmin in a long-running vacuum

? Regards, Nikhils -- EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] log_autovacuum

IMHO, it would be good to have both the messages spit out. The earlier message is much better for parsing and the later makes READABLE sense. Regards, Nikhils -- EnterpriseDB http://www.enterprisedb.com

[PATCHES] Auto Partitioning Patch - WIP version 1

, UNIQUE information specified, pass it on to the children tables. vi) [stretch goal] Support HASH partitions Will try to complete the above mentioned TODOs as soon as is possible. Comments, feedback appreciated. Thanks and Regards, Nikhils -- EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] CREATE TABLE LIKE INCLUDING INDEXES support

e to remove the syntax support for "INCLUDING INDEXES" and just add code to the existing WITH CONSTRAINTs code path from his patch. Is there something else and hence we have the above TODO? Regards, Nikhils -- EnterpriseDB http://www.enterprisedb.com

[PATCHES] UPDATE using sub selects

update.sql regression test to include possible variations . No documentation changes are present in this patch. Feedback, comments appreciated. Regards, Nikhils -- EnterpriseDB http://www.enterprisedb.com ? GNUmakefile ? config.log ? config.status ? cscope.out ? src/Makefile.global

Re: [PATCHES] CREATE TABLE LIKE INCLUDING INDEXES support

, + (errmsg("Index \"%s\" cloned.", + RelationGetRelationName(parent_index; DefineIndex will give out a message anyways for unique/primary keys. The above seems additional to it. Regards, Nikhils -- EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] CREATE TABLE LIKE INCLUDING INDEXES support

lumns. Since this patch is only supposed to copy unique/primary indexes, I dont think we will ever have predicates associated to such indexes? Regards, Nikhils -- EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] CREATE TABLE LIKE INCLUDING INDEXES support

Hi, On 5/3/07, Tom Lane <[EMAIL PROTECTED]> wrote: NikhilS <[EMAIL PROTECTED]> writes: > Hi Neil, >> * the patch is broken for expressional indexes, and silently omits >> copying the predicate that may be associated with an index. > Since this patch is only s

Re: [PATCHES] CREATE TABLE LIKE INCLUDING INDEXES support

use syntax. Any specific reason for this behaviour? If we want to pass such kinds of expr, predicate based constraints via the "LIKE .. INCLUDING CONSTRAINTS" statements, transformIndexConstraints as well as the Constraint structure might need modifications. Regards, Nikhils --

Re: [PATCHES] CREATE TABLE LIKE INCLUDING INDEXES support

O we should be uniform about unique constraints semantics. That might mean that we only support expressionless, non-predicate indexes via "INCLUDING CONSTRAINTS"? Regards, Nikhils -- EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] CREATE TABLE LIKE INCLUDING INDEXES support

and will send it to Neil for review tommorrow. Regards, Nikhils -- EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] CREATE TABLE LIKE INCLUDING INDEXES support

test case also contains some more additions with this patch. Please let me know if there are any issues. Also, if this patch is acceptable, I think the mechanism provided here can be used to support "INCLUDING INDEXES" case easily too. Regards, Nikhils -- EnterpriseDB htt

Re: [PATCHES] CREATE TABLE LIKE INCLUDING INDEXES support

n Oids and make ProcessUtility accept a new nodeTag. We will also not be able to use existing Index definition functions and this will lead to more coding IMHO. Do we want to go down this path? Or is there something else that has been suggested above and that I am missing completely? Please let me know. R

Re: [PATCHES] CREATE TABLE LIKE INCLUDING INDEXES support

am missing completely? OTOH, we can populate a new structure with the relevant Oids, IndexInfo information from parent relation indexes and call index_create directly from within ProcessUtility. Guess, it should be cleaner than the current approach. Regards, Nikhils -- EnterpriseDB

Re: [PATCHES] CREATE TABLE LIKE INCLUDING INDEXES support

Hi, On 5/23/07, NikhilS <[EMAIL PROTECTED]> wrote: Hi, > The index creation happens after the new table (which is LIKE the > parent) has been created, by appending the cxt.alist information to > "extras_after". The entry point for the index creation is thus via >

Re: [PATCHES] CREATE TABLE LIKE INCLUDING INDEXES support

Hi, On 5/23/07, Tom Lane <[EMAIL PROTECTED]> wrote: NikhilS <[EMAIL PROTECTED]> writes: > If so, I think we can introduce 2 Oid fields in the IndexStmt structure and > store the Oids there. In DefineIndex we can use these Oids if they are not > invalid. I think this i

Re: [PATCHES] CREATE TABLE LIKE INCLUDING INDEXES support

If it's not then this not a problem at all so the existing patch is fine. I doubt if accessMethod name will change. The tableSpace name can change, but the possibility is no worse to doing a [CREATE TABLE table_name ... TABLESPACE tablespace]. So this should be reasonably ok. R

Re: [PATCHES] CREATE TABLE LIKE INCLUDING INDEXES support

Hi, On 6/3/07, Neil Conway <[EMAIL PROTECTED]> wrote: On Mon, 2007-21-05 at 12:23 +0530, NikhilS wrote: > I had spent some time on this earlier so decided to complete and send > the patch to you for review. This patch supports copying of > expressions, predicates, opclass, amor

Re: [PATCHES] CREATE TABLE LIKE INCLUDING INDEXES support

ty introduced herein will be useful in the "CREATE .. INCLUDING INDEXES" case too. Regards, Nikhils -- EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] CREATE TABLE LIKE INCLUDING INDEXES support

d on the latest version which was posted by Neil. Please let me know if there are any issues. Regards, Nikhils -- EnterpriseDB http://www.enterprisedb.com Index: doc/src/sgml/ref/create_table.sgml === RCS file: /repo

Re: [PATCHES] CREATE TABLE LIKE INCLUDING INDEXES support

nging to the parent index into some form which could be consumed by transformRelOptions(). It was difficult to convert it into a list of DefElem entries and hence I had to introduce inhreloptions. Regards, Nikhils -- EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] CREATE TABLE LIKE INCLUDING INDEXES support

uot; or "inh_idxoptions"? Your call :). Regards, Nikhils -- EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

Re: [PATCHES] CREATE TABLE LIKE INCLUDING INDEXES support

ndex clearer? To reiterate its a minor nitpick really from my side and can be ignored too. Regards, Nikhils -- EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster

Re: [PATCHES] [DOCS] Partition: use triggers instead of rules

be seeing that construct in real > > databases. > > And they could refer back to the older version of the documentation for > it. In fact, we should mention that in the patch: > > If you have a partitioning setup that uses rules please > refer to the 8.2 documentation

Re: [PATCHES] [DOCS] Partition: use triggers instead of rules

down which partitions should actually receive the updates and > deletes. > I think triggers are the only solution for insert though. > Another reason to go along with triggers is that "COPY" honors triggers, but does not honor rules. While trying to do bulk inserts into a parent of partitioned tables where rules are being employed, the COPY operation will not be so straightforward. Regards, Nikhils -- EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] UPDATE using sub selects

uire some more work too. So for example, something of this sort does not work yet: UPDATE update_tbl set (a, b) = (select a, b from other_tbl where c = update_tbl.c) where a = 10; I will try to have another shot at it if I can, before the next commit fest. Thanks and Regards, Nikhils -- EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] Auto Partitioning Patch - WIP version 1

Hi Simon, On Fri, Mar 21, 2008 at 7:30 PM, Simon Riggs <[EMAIL PROTECTED]> wrote: > On Fri, 2007-03-30 at 12:28 +0530, NikhilS wrote: > > > Please find attached the WIP version 1 of the auto partitioning patch. > > There was discussion on this a while back

Re: [PATCHES] Auto Partitioning Patch - WIP version 1

Hi, On Fri, Mar 21, 2008 at 9:23 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > NikhilS wrote: > >> Thanks for taking a look. But if I am not mistaken Gavin and co. are > working > >> on a much exhaustive proposa

Re: [PATCHES] [EMAIL PROTECTED]: Re: [BUGS] Problem identifying constraints which should not be inherited]

there is an issue introduced in the CREATE TABLE REFERENCES code path due to your patch (this is without my pg_dump changes just to be sure). Looks like some memory overwrite issue. The trace is as follows: Core was generated by `postgres: nikhils regression [local] CREATE TABLE

Re: [PATCHES] [EMAIL PROTECTED]: Re: [BUGS] Problem identifying constraints which should not be inherited]

language, but shouldn't that be worded as "children tables"? Admittedly even this does not sound any better than "child tables" though :). It is nit-picking really, but I can submit a cleanup patch to reword this if the list thinks so.. Regards, Nikhils -- EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] Exposing keywords to clients

UID 12 10 400 f f t t s 0 2249 e) I was wondering why pronargs is set to 0 above. But I see other functions doing the same, so its ok I guess for such kinds of usages. PFA, version 4 of this patch with a,c and d taken care of. Regards, Nikhils -- EnterpriseDB http://www.enterprisedb.com Index: