Gavin,
Personally, I'd love to see some of these newer data analysis
capabilities added to PostgreSQL -- or at least put out there as
interesting patches.
I think if the code is good enough, and we can avoid horrible non-standard
syntax extensions, they should go in. We have to defend our
On 3/7/07, Hannu Krosing [EMAIL PROTECTED] wrote:
Do any of you know about a way to READ PAGE ONLY IF IN CACHE in *nix
systems ?
Supposedly you could mmap() a file and then do mincore() on the
area to see which pages are cached.
But you were talking about postgres cache before, there it
Am Mittwoch, 7. März 2007 07:44 schrieb NikhilS:
Sure, but as Chris mentioned earlier, wouldn't it be useful to maintain
uniqueness on a
partition-by-partition basis too?
Many things might be useful, but the aim of the table partitioning venture
is believed to be the provision of a
On Tue, 2007-03-06 at 18:31 +0530, NikhilS wrote:
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
I've updated the GIT patch at http://community.enterprisedb.com/git/.
Bitrot caused by the findinsertloc-patch has been fixed, making that
part of the GIT patch a little bit smaller and cleaner. I also did some
refactoring, and minor cleanup and commenting.
Any comments on the design or
Hi,
If you know that the constraints on each of the tables is distinct, then
building a UNIQUE index on each of the partitions is sufficient to prove
that all rows in the combined partitioned table are distinct also.
The hard part there is checking that the partition constraints are
distinct.
my only question would be.
Why isn't that in core already ?
---(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
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 multiple tables?
Many partitioning schemes have (or can be made to have) only one
possible
+1
On 3/7/07 6:53 AM, Grzegorz Jaskiewicz [EMAIL PROTECTED] wrote:
my only question would be.
Why isn't that in core already ?
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an
Hi,
On 3/7/07, Zeugswetter Andreas ADI SD [EMAIL PROTECTED] 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 multiple tables?
Many
I don't think it is common. I didn't add that part, so if
you also think it is rare, I will remove that distinction. New text:
liPostgreSQL is licensed under a BSD license. By posting a
patch
to the public PostgreSQL mailling lists, you are giving the
PostgreSQL
Global
I am wondering if we can implement unique indexes across several tables
(inheritance hierarchy) not by using a single, big index covering all
the tables, but rather by inserting a dummy entry into each partition's
unique index. This dummy entry would have an expanded CTID which would
include the
Josh Berkus josh@agliodbs.com writes:
I think if the code is good enough, and we can avoid horrible non-standard
syntax extensions, they should go in. We have to defend our title as most
advanced database and having stuff like Skyline first (before DB2 or MS)
goes a long way for that.
Simon,
On 3/7/07 5:26 AM, Simon Riggs [EMAIL PROTECTED] wrote:
What is really needed is a data structure that allows range partitions
to be accessed more efficiently. This could make adding partitions and
deciding in which partition a specific value goes an O(logN) operation.
I think we need
Teodor Sigaev [EMAIL PROTECTED] writes:
input value. As I remember, only R-Tree emulation over boxes, contrib/seg
and
contrib/cube have simple compress method.
Hm, if they just return the original datum without detoasting it then it
could
be an issue. I'll check.
seg and box aren't a
On Wed, 2007-03-07 at 10:23 -0500, Luke Lonergan wrote:
Simon,
On 3/7/07 5:26 AM, Simon Riggs [EMAIL PROTECTED] wrote:
What is really needed is a data structure that allows range partitions
to be accessed more efficiently. This could make adding partitions and
deciding in which
Jeroen,
On 3/5/07 12:39 PM, Jeroen T. Vermeulen [EMAIL PROTECTED] wrote:
I guess if you did simple run-length compression on these bitmaps you'd
end up more or less where I came in. But you wouldn't want to flip a bit
somewhere in the middle of a compressed data stream, of course. :-
We
I'm already started, don't worry about that. Cube is broken since TOAST
implemented :)
Gregory Stark wrote:
Teodor Sigaev [EMAIL PROTECTED] writes:
input value. As I remember, only R-Tree emulation over boxes, contrib/seg and
contrib/cube have simple compress method.
Hm, if they just return
Hi,
I made some tests to prove that GENERATED can help
boost performance. I created a table like this:
create table t1 (
id serial,
i1 integer,
i2 integer,
g1 integer generated always as (
case when i1 is null then i2
when i2 is null then i1
else i1
What is really needed is a data structure that allows range
partitions
to be accessed more efficiently. This could make adding partitions
and
deciding in which partition a specific value goes an O(logN)
operation.
I think we need to re-evaluate the inheritance mechanism for
Hi,
I am right now working on to get HOT and VACUUM FULL work
together. I hit upon a bug which I initially thought is
something that HOT has introduced. But I can reproduce
it with CVS HEAD as well.
Here is what I do: Create a table a simple table with
three columns and one index. Insert a
The query Ranbeer gave - as with any skyline query - can be solved with
just pure SQL:
select * from books b where not exists(
select * from books b2 where
b2.rating = b.rating and b2.price = b.price and
(b2.rating b.rating or b2.price b.price)
);
book_name | rating | price
Tom,
My questions about whether to adopt it have more to do with
cost/benefit. I haven't seen the patch, but it sounds like it will be
large and messy; and it's for a feature that nobody ever heard of before,
let alone one that the community has developed a consensus it wants.
I'm not
Pavan Deolasee [EMAIL PROTECTED] writes:
I am right now working on to get HOT and VACUUM FULL work
together. I hit upon a bug which I initially thought is
something that HOT has introduced. But I can reproduce
it with CVS HEAD as well.
I think we broke this in 8.2: vac_update_relstats needs
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Alvaro Herrera
Sent: woensdag 7 maart 2007 15:59
To: NikhilS
Cc: Zeugswetter Andreas ADI SD; Peter Eisentraut;
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Auto creation of Partitions
I am wondering
On Mar 6, 2007, at 9:43 AM, Josh Berkus wrote:
Don't get me wrong, I want things to be easily understandable as well
but the reason you site above pretty much
makes us need to remove most of the postgresql.conf, including all
bgwriter, vacuum cost delay, and autovac settings.
Not to mention
On Wed, 2007-03-07 at 10:32 +, Heikki Linnakangas wrote:
I've been thinking
we should call this feature just Clustered Indexes
Works for me.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of
On Fri, 2007-03-02 at 11:09 -0800, David Fetter wrote:
On Fri, Mar 02, 2007 at 10:52:14AM -0800, Joshua D. Drake wrote:
Hello,
Unfortunately we (the community) will not have WITH/RECURSIVE for 8.3.
However I have spoken with a Alexey and Alvaro and Command Prompt has
decided to make
On Mar 6, 2007, at 10:11 PM, ITAGAKI Takahiro wrote:
I have some results that if we have plenty of time for checkpoints,
bgwriter_all_maxpages is not a so important parameter because it is
adjusted to shared_buffers / duration of checkpoint.
Also, my recommended bgwriter_lru_maxpages is average
Josh Berkus wrote:
Now, I don't know if this Skyline patch is our answer for approximate queries.
Maybe I should pester Meredith about getting QBE free of its IP issues; it
certainly looked more flexible than Skyline. In either case, the code
probably needs a complete refactor.
But I
On Wed, 7 Mar 2007, Josh Berkus wrote:
Approximate queries is something with DSS users *want*. Jim Grey addressed
this in his ACM editiorial on the databases of the future. It's something
that *I* want, and if the Greenplum people aren't speaking up here, it's
because they're not paying
Yep - we're paying attention Josh!
I like the category being explored with skyline, I'm not sure yet how it fits
with existing 'soft data' models and applications that use them.
If SKYLINE is interesting to app developers, maybe we should consider it for
Bizgres?
- Luke
Msg is shrt cuz m on
Hackers,
I want to propose some very simple changes to autovacuum in order to
move forward (a bit):
1. autovacuum_naptime semantics
2. limiting the number of workers: global, per database, per tablespace?
I still haven't received the magic bullet to solve the hot table
problem, but these at
I'd like to change ProcessUtility to take a couple of additional
parameters, which it in turn would pass down to those (relatively few)
utility statements that need one or both:
* query_string: source text of command, if known (can be NULL)
* is_top_level: TRUE if command is being driven directly
Alvaro Herrera [EMAIL PROTECTED] writes:
Is everybody OK with changing the autovacuum_naptime semantics?
it seems already different from 8.2, so no objection to further change.
Is everybody OK with not putting a per-tablespace worker limit?
Is everybody OK with putting per-database worker
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2007-03-02 at 11:09 -0800, David Fetter wrote:
On Fri, Mar 02, 2007 at 10:52:14AM -0800, Joshua D. Drake wrote:
Hello,
Unfortunately we (the community) will not have WITH/RECURSIVE for 8.3.
However I have spoken with a Alexey and Alvaro
Tom Lane [EMAIL PROTECTED] writes:
* is_top_level: TRUE if command is being driven directly from
exec_simple_query or exec_execute_message, else FALSE (this would
need to be passed through PortalRun, so it gets this parameter added
too).
...
The point of adding is_top_level is to
On Wed, 2007-03-07 at 10:32 +, Heikki Linnakangas wrote:
I've been thinking
we should call this feature just Clustered Indexes
So we would have clustered tables which are tables whose heap is ordered
according to an index and separately clustered indexes which are indexes
optimized for
Any chance we can get WITH without RECURSIVE? That would be very
handy all by itself.
I thought Greg already did submitted that?
To my knowledge, it is not done. If it is, great!
Joshua D. Drake
---(end of broadcast)---
TIP 4: Have
Tom Lane wrote:
Josh Berkus josh@agliodbs.com writes:
I think if the code is good enough, and we can avoid horrible non-standard
syntax extensions, they should go in. We have to defend our title as most
advanced database and having stuff like Skyline first (before DB2 or MS)
goes a long way
Alvaro,
Alvaro Herrera wrote:
I still haven't received the magic bullet to solve the hot table
problem, but these at least means we continue doing *something*.
Can I know about what is your plan or idea for autovacuum improvement
for 8.3 now? And also what is the roadmap of autovacuum
Andreas,
On 3/7/07 11:45 AM, Zeugswetter Andreas ADI SD [EMAIL PROTECTED]
wrote:
Whoa, do you have anything to back that up ?
Sure - when we start to consider designs that implement advanced data
management features, we run into problems with the architecture of
tables-tables-tables Here
On Wed, 7 Mar 2007, ITAGAKI Takahiro wrote:
Also, my recommended bgwriter_lru_maxpages is average number of
recycled buffers per cycle, that is hardly able to tune manually.
This is completely dependent on what percentage of your buffer cache is
pinned. If your load is something like the
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
The point of adding is_top_level is to provide a simpler, more reliable
means for PreventTransactionChain and related functions to detect
whether a function is trying to invoke a non-transaction-block-safe
command.
On Mar 4, 2007, at 3:33 PM, Ryan Cumming wrote:
I did another 18 runs, 9 each for huge pages and normal shared memory.
The database was reinitialized before every third run with pgbench -i
-s 10. The runs themselves were done with pgbench -s 10 -c 5 -t
1
Rather than doing that, I think
On Mar 6, 2007, at 9:13 AM, Shane Ambler wrote:
NikhilS wrote:
On 3/6/07, Peter Eisentraut [EMAIL PROTECTED] wrote:
1) Whether we should use triggers/rules for step number (iii) above.
Maybe rules is the way to go.
Since this would basically be a case of the updatable rules
problem, you
On Mar 6, 2007, at 4:57 AM, NikhilS wrote:
iv) Based on the PRIMARY, UNIQUE, REFERENCES information specified,
pass it on to the children tables.
Since we want to eventually support 'global' indexes, I think we need
to be really careful here. There's actually 3 possible cases:
1) Index*
On Mar 7, 2007, at 3:26 AM, Simon Riggs wrote:
If you know that the constraints on each of the tables is distinct,
then
building a UNIQUE index on each of the partitions is sufficient to
prove
that all rows in the combined partitioned table are distinct also.
The hard part there is checking
On Mar 7, 2007, at 4:00 PM, Alvaro Herrera wrote:
Is everybody OK with putting per-database worker limits on a
pg_database
column?
I'm worried that we would live to regret such a limit. I can't really
see any reason to limit how many vacuums are occurring in a database,
because there's
Shane Ambler [EMAIL PROTECTED] writes:
Tom Lane wrote:
Well, whether it's horrible or not is in the eye of the beholder, but
this is certainly a non-standard syntax extension.
Being non-standard should not be the only reason to reject a worthwhile
feature.
No, but being non-standard is
Tom Lane wrote:
Please check if this makes it go away for you --- I'm a bit busy
at the moment.
Thanks a lot, Tom. It seems to work fine for me. I will do some
more tests and report if I see any issue. Btw, the patch as per
your suggestion is attached.
Thanks,
Pavan
***
51 matches
Mail list logo
