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: doc/src/sgml/func.sgml
===
RCS file: /repositories/postgreshome/cvs/pgsql/doc/src
,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
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 '.
Program terminated with signal 11, Segmentation fault.
#0 0x08378024 in AllocSetCheck (context
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 on -hackers at:
http
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 proposal. In light of that maybe this patch might
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
.
And they could refer back to the older version of the documentation for
it. In fact, we should mention that in the patch:
noteparaIf you have a partitioning setup that uses rules please
refer to the 8.2 documentation on partitioning/para/note
+1
Regards,
Nikhils
--
EnterpriseDB
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
,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
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
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: /repositories/postgreshome/cvs/pgsql/doc/src/sgml/ref
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, amorder, reloptions etc
in the CREATE .. INCLUDING INDEXES case too.
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
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 http
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
ProcessUtility which expects
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 is just make-work that causes
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.
Regards,
Nikhils
--
EnterpriseDB http
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 http://www.enterprisedb.com
Index
tommorrow.
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
constraints semantics.
That might mean that we only support expressionless, non-predicate indexes
via INCLUDING CONSTRAINTS?
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
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
--
EnterpriseDB
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 supposed to copy unique/primary indexes, I
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
,
+ (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
the 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
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
, 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
. The earlier
message is much better for parsing and the later makes READABLE sense.
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
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
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 http
32 matches
Mail list logo
