twice, the
rd_refcnt for table "foo" is bumped up to 2, causing the above failure.
We might want to add a step to ExecuteTruncate(), or whatever calls it, to
make the list unique.
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
quot; word for this very reason.
But consider for example when the datum type is PLPGSQL_DTYPE_REC. I dont
think its justified to have the overhead of heap_copytuple_with_tuple, when
all we need is just the typeid! Similar arguments apply for other datums
like PLPGSQL_DTYPE_ROW, PLPGSQL_DTYPE_TRIGAR
exec_eval_datum could
itself be modified for cases where we just need the datum type. Should I
cook up a patch for this? I am inclined towards introducing a new function
(but that means that any new datum related changes need to be carried out in
2 functions instead of one currently).
Regards,
Nikhils
unced back for a non-context diff :)
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
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
naming, commeting, coding conventions
should come naturally as it can aide in copy-pasting too :)
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
ould be used to generate the new resultant values before
doing a heap_form_tuple. E.g.
(col1 transform "col1 + 10", col2 transform "col1 * col2", col3 transform
"UPPER(col1 || col3)",...)
I have spent some thoughts on how to do this and will be happy to share the
Hi Alvaro
On Fri, Mar 28, 2008 at 6:05 PM, Alvaro Herrera <[EMAIL PROTECTED]>
wrote:
> NikhilS escribió:
>
> > I will take a look at the pg_dump related changes if you want. We will
> need
> > changes in flagInhAttrs() and in getTableAttrs() to query the backend
>
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
Hi Alex,
On Fri, Mar 28, 2008 at 4:58 AM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 27, 2008 at 5:14 AM, NikhilS <[EMAIL PROTECTED]> wrote:
> > * Add logic to disallow ADD CONSTRAINT ONLY to parent of an inheritance
> > hierarchy
> >
> > * Add
ready
mentions that we should make changes in pg_constraint to avoid this
rudimentary way of determing the inheritance :).
Am important decision here is about adding a new attribute to pg_constraint
as it is the only sane way of determining inherited constraints, but that
will require an initdb. Comm
src/backend/utils/mmgr/README contains more information about the same too.
Regards,
Nikhils
On Thu, Mar 20, 2008 at 2:41 PM, Pavan Deolasee <[EMAIL PROTECTED]>
wrote:
> On Thu, Mar 20, 2008 at 12:27 AM, Dan Searle <[EMAIL PROTECTED]> wrote:
>
> >
> > I had
Hi Longlong,
> > i think this is a better idea.
> from *NikhilS *
> http://archives.postgresql.org/pgsql-hackers/2007-12/msg00584.php
> But instead of using a per insert or a batch insert substraction, I am
> thinking that we can start off a subtraction and continue it til
rule out the existing
> partitioning for many applications. We need it for our own stuff! :P
>
Agreed, syntax is just the sugar.
Also other than performance, how are updates involving partition keys
causing the resultant tuple to end up in a new partition handled here?
Regards,
Nikhils
--
Ente
e
> and list specifications don't overlap.
>
Detection of mutually exclusive ranges might not turn out to be so easy
afterall. I think there is some code in the constraint_exclusion area which
might help out in this.
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
artition set 'becomes' the table and
vice-versa. Essentially, we'd swap the relfilenodes. This means that we
have to first ADD PARTITION then swap the table and the partition.
Thoughts?
<..>
Surely this wont be instantaneous?
<..>
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
be a common check in both "COPY TO" and "COPY FROM" cases
source/destination being STDIN or otherwise. While it definitely makes sense
for the FROM case maybe we could relax this for the COPY TO case.
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
Hi,
On Dec 15, 2007 1:14 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> NikhilS <[EMAIL PROTECTED]> writes:
> > Any errors which occur before doing the heap_insert should not require
> > any recovery according to me.
>
> A sufficient (though far from all-encompassing)
go ahead with
the start of a new subtransaction.
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
form a new set of
values[], nulls[] entries before forming the corresponding tuple entry.
I think the above will be a very useful enhancement to COPY. The syntax and
other details mentioned above are ofcourse subject to discussion and
approval on the list.
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
confusing. I believe we should remove the following TODO
now that the above has been checked in:
CREATE
- Have WITH CONSTRAINTS also create constraint indexes
http://archives.postgresql.org/pgsql-patches/2007-04/msg00149.php
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
.com/Re%3A-CREATE-TABLE-LIKE-INCLUDING-INDEXES-support-p10683716.html
maybe we should not?
In other words "INCLUDING INDEXES" should only create those indexes which do
not have isconstraint set to TRUE.
Comments?
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
was) and that was turned down.
> >
>
> Agreed :), for the record, my name is "Nikhil Sontakke".
>
> Regard,
> Nikhils
> --
>
> EnterpriseDB http://www.enterprisedb.com
>
g for
list_length(cref->fields) being greater than 1 before calling this in
transformExpressionList?
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
Apologies! As Alvaro guessed it correctly I was working with 8.2 sources.
Sorry for the noise.
Regards,
Nikhils
On 8/29/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> NikhilS <[EMAIL PROTECTED]> writes:
> > The attached patch should fix this.
>
> And break other thin
resetStringInfo() a bit
puzzling. A found a lot of places where the code was resetting the "len"
field to 0 and assigning '\0' to the data field to reset the variable. This
seems to be the only missing API which will be needed while working with the
StringInfo type.
Regards,
Ni
a context which
becomes a direct child of TopMemoryContext. Wouldn't it be a better idea to
create the table in CurrentMemoryContext?
If hash_destroy() is not explicitly invoked, this can cause a lot of bloat
especially if the intention was to use the hash table only for a while.
Regards,
Nikhi
ng some code and valgrind is not of much help
in such cases because of this very beauty of memory contexts :).
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
nformation_schema.sql file (I dont know if this is the
recommended way though). These will end up becoming a part of template1 and
any subsequent databases that are created will contain them.
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
Hi,
On 4/12/07, Merlin Moncure <[EMAIL PROTECTED]> wrote:
On 4/12/07, NikhilS <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Shouldn't the final command below cause a 'column "b" does not exist
error'?
>
> create table update_test (a int, b int);
>
b from supdate_test) from update_test;
a ?column?
-- -
2030
Is the problem with the code in colNameToVar or maybe we should add checks
in transformSubLink?
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
is
I have added a new field in the "Query" structure. This entry gets
preprocessed similar to other fields of the Query from within
subquery_planner.
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
integer |
Indexes:
"parent_a_key" UNIQUE, btree (a)
Inherited by: child
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
So we are unable to load any of the tables using COPY.
Aww, guess should have stuck to triggers as a first choice. Mea culpa, since
I should have investigated some more before deciding on rules, or should
have prodded you more earlier:)
Regards,
Nikhils
--
EnterpriseDB http
WHERE child_1.a = old.a
Whereas a describe on the child shows the following:
postgres=# \d child_1
Table "public.child_1"
Column | Type | Modifiers
+-+---
a | integer |
b | integer |
Indexes:
"child_1_a_key" UNIQUE, btree (a)
Check c
ossible) to make it easier for people getting in.
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
said that, obviously I would want to go with the consensus on this
list as to what we think is the *best* way to go forward with partitioning.
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
ould see in the code.
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
Hi,
On 3/31/07, Tom Lane <[EMAIL PROTECTED]> wrote:
NikhilS <[EMAIL PROTECTED]> writes:
> I have invented a ROWEXPR_SUBLINK type that handles multiple output
columns.
> The trouble is that since eventually columns of the parents have to be
part
> of the query's ta
mal "SET colname = expr" targets).
Is there a simpler way of doing things? Should I try generating a resjunk
TargetEntry in transformUpdateStmt and have its expr point to the subquery
and see if that works?
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
Hi,
On 3/16/07, Tom Lane <[EMAIL PROTECTED]> wrote:
NikhilS <[EMAIL PROTECTED]> writes:
> To allow both of the above to hold, I think the subselect will have to
be
> treated like a EXPR_SUBLINK subquery. I was wondering if we have a
similar
> mechanism for plain selects/su
bquery. I was wondering if we have a similar
mechanism for plain selects/subselects to check and restrict their output to
a single row.
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
getting a syntax error, even after
making all the changes.
Grzegorz, I would have suggested to make an entry for VERBOSE in
parser/keywords.c, but it already seems to contain an entry for VERBOSE. I
hope you are using the "opt_verbose" rule in your gram.y in the CLUSTER
[VERB
w, seems to work:
UPDATE update_test SET (a,b) = (select a,b FROM update_test where c = 'foo')
WHERE a = 10;
Will try testing out some other variations too.
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
syntax, what changes and
where all they need to be made with respect to the documentation?
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
nce, to catch such cases.
That again means that the onus is on the partition creator most of the
times..
Regards,
Nikhils
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
EnterpriseDB http://www.enterprisedb.com
abase ?
Thats why I would prefer the existing mechanism, there a DROP on the child
removes it and a NO INHERIT disassociates it. There might be situations
where we would want to just disassociate and not drop.
Regards,
Nikhils
--
Hannu Krosing
Database Architect
Skype Techn
2;
else if (date_col < D3)
return 3;
return 4;
}
Doing it this way would allow us to easily join two tables based upon a
common partition function.
In time, I would suggest we support both ways: declarative and
functional.
Till now, we are going the declar
a default "DUMP/DUMB" partition.
Given that Simon wants to do away with having the master table APPENDed in
the planning phase, this would be better.
Regards,
Nikhils
--
Shane Ambler
[EMAIL PROTECTED]
Get Sheeky @ http://Sheeky.Biz
--
EnterpriseDB http://www.enterprisedb.com
use the ALTER TABLE to add partitions)
ALTER TABLE tabname
ADD PARTITION partition_name CHECK(...)
[USING TABLESPACE tblspcname];
We could as well drop the USING part.
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
the job to deal with the partition. Do we want to reinvent additional syntax
when these are around and are documented?
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
in its own
index and follow it up with dummy entries update into other partitions if
the need be.
Ofcourse as you have mentioned all of this so needs to be done after a
careful think on the locking/deadlocking etc issues.
Regards,
Nikhils
On 3/7/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
cover the other cases.
Andreas
Yes, I agree. For version 1, UNIQUE/PRIMARY indexes will cascade down to the
child table, only if the indexed column is present as part of the
partitioning rule.
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
While partitioning, the additional onus on the user is to specify
non-conflicting CHECKs for the range/list partitions.
Regards,
Nikhils
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
--
EnterpriseDB http://www.enterprisedb.com
pport auto-partitioning on the primary key, and that
restriction avoids the indexing problem.
regards, tom lane
Sure, but as Chris mentioned earlier, wouldn't it be useful to maintain
uniqueness on a
partition-by-partition basis too?
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
Hi Shane,
Maybe I'm looking at auto-maintenance which is beyond any current planning?
Many of your suggestions are useful, but auto-maintenance will be beyond the
current plan.
Regards,
Nikhils
EnterpriseDB http://www.enterprisedb.com
Hi,
On 3/6/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
"NikhilS" <[EMAIL PROTECTED]> writes:
>the intention is to use this information from the parent and make it a
>property of the child table. This will avoid the step for the user having
to
>manually specif
On 3/6/07, NikhilS <[EMAIL PROTECTED]> wrote:
Hi,
On 3/6/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
>
> "NikhilS" <[EMAIL PROTECTED]> writes:
>
> >the intention is to use this information from the parent and make it a
> >property of the c
Hi,
On 3/6/07, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
NikhilS wrote:
> iv) Based on the PRIMARY, UNIQUE, REFERENCES information specified,
> pass it on to the children tables.
How will you maintain a primary key in such a table, considering that
indexes can't span multi
ting these rules.
Comments appreciated,
Regards,
Nikhils
EnterpriseDB http://www.enterprisedb.com
lead to
more critical usage elsewhere... But agreed, it is hard to show with just
some performance runs.
Regards,
Nikhils
On 3/5/07, Stefan Kaltenbrunner <[EMAIL PROTECTED]> wrote:
Tom Lane wrote:
> NikhilS <[EMAIL PROTECTED]> writes:
>> What is the opinion of the list
(single digit percentage)
of (NBuffers
* int) size. I have done pgbench/dbt2 runs and I do not see any negative
impact because of this. Are there any other suggestions for measuring the
backend memory footprint?
Regards,
Nikhils
On 2/21/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Added t
Hi,
On 2/2/07, Gavin Sherry <[EMAIL PROTECTED]> wrote:
On Fri, 2 Feb 2007, NikhilS wrote:
> Hi,
>
> Indeed it does, apologies for not doing the entire groundwork. But what
it
> also does is that it adds -O2 by default for gcc even when
--enable-debug is
> specifie
becomes
difficult. Has this issue been faced by anybody else? If so can try out a
patch to avoid using O2 with enable-debug.
Regards,
Nikhils
On 2/2/07, Gavin Sherry <[EMAIL PROTECTED]> wrote:
On Fri, 2 Feb 2007, NikhilS wrote:
> Hi,
>
> configure with --enable-debug does not seem
= yes; then
CFLAGS="$CFLAGS -g"
fi
--- 300,315
# supply -g if --enable-debug
! if test "$enable_debug" = yes && (test "$ac_cv_prog_cc_g" = yes ||
! test "$ac_cv_prog_gcc_g" = yes); then
CFLAGS="$CFLAGS -g&qu
calized in the buf_init.c and bufmgr.c files only.
Comments please.
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
5 minutes, or no vaccuums ?
We tried with both. Vacuum seems to do little to help in a long running transaction case. Generally in most of the pgbench runs that we carried out, autovacuum did not seem to be of much help even to PG82.
Regards,
Nikhils-- EnterpriseDB http://www.enterprisedb.com
nd 25000 transactions produce similar percentage increases with the HOT update patch.
Regards,
Nikhils
-- EnterpriseDB http://www.enterprisedb.com
rflow relations.
Regards,Nikhils-- EnterpriseDB http://www.enterprisedb.com
end up
doing multiple index scans for them. In case of HOT updates, we have a
single index entry with the chains getting traversed from the overflow
relation. So as Simon has mentioned the need to avoid long chains remains
a difficulty for both the situations.
Regards,
Nikhils
-- Ente
.
Since these can be turned on a per file basis, perf testing them out should be simpler too.
Regards,
Nikhils
On 10/25/06, Martijn van Oosterhout <kleptog@svana.org> wrote:
On Tue, Oct 24, 2006 at 12:53:23PM -0700, Ron Mayer wrote:> Anyway, for those who want to see what they do
tgres codebase which provides microseconds level of delay coupled with SIGALRM support?
Regards,
Nikhils
EnterpriseDB http://www.enterprisedb.com-- All the world's a stage, and most of us are desperately unrehearsed.
i/o is generally poorly supported.
Async i/o is stably supported on most *nix (apart from Linux 2.6.*) plus Windows.
Guess it would be still worth it, since one fine day 2.6.* will start supporting it properly too.
Regards,
Nikhils
> Is it worth considering using readv(2) instead?Er
ve, do you mean the number of pages that could not be added
to the FSM because they had freespace which was less than the threshold
for this particular relation?
Regards,
Nikhils
EnterpriseDB http://www.enterprisedb.com
On Wed, Oct 18, 2006 at 11:27:39AM +0530, NikhilS wrote:>
Hi,
"bgwriter doing aysncronous I/O for the dirty buffers that it is supposed to sync"
Another decent use-case?
Regards,
Nikhils
EnterpriseDB http://www.enterprisedb.com
On 10/15/06, Luke Lonergan <[EMAIL PROTECTED]> wrote:
Martijn,On 10/15/06 10:56 AM, "Martijn van
Hi,
So:
heap_blks_reused (with Jim's semantics), heap_blks_extend,
heap_blks_truncate are the "interesting" stats? Will try to work up a
patch for this.
Regards,
Nikhils
EnterpriseDB http://www.enterprisedb.com
On 10/15/06, Simon Riggs <[EMAIL PROTECTED]> wrote:
On Sat
Hi Jim,
On 10/13/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
On Fri, Oct 13, 2006 at 06:17:47PM +0530, NikhilS wrote:> Currently a "select * from pg_statio_user_tables;" displays only
> heap_blks_read, heap_blks_hit stats amongst others for the main relation. It>
the above. Any thought/comments?
Regards,
Nikhils
(www.enterprisedb.com)-- All the world's a stage, and most of us are desperately unrehearsed.
79 matches
Mail list logo
