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
*** src/backend/comm
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-standar
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 no
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 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* sh
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 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 thin
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
>
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 s
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..."
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 improve
Tom Lane wrote:
Josh Berkus 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.
Wel
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
> 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
optimi
"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
"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 Al
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
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
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 leas
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 m
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 payin
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 thi
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 "averag
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
> > decide
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 broadcast)--
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 commi
>-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
"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
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 i
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 | pr
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 sing
> > 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
> p
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 +
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 ret
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. :-
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
"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 a
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 w
Josh Berkus 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.
Well, whether
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 t
> 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:
>
> PostgreSQL is licensed under a BSD license. By posting a
patch
> to the public PostgreSQL mailling lists, you are giving the
PostgreSQL
> Global D
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?
M
+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
>cho
> > 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
possib
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
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. I
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 patch?
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
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 transp
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 shou
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 ou
51 matches
Mail list logo
