On Jan 9, 2008 9:51 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> "Warren Turkal" <[EMAIL PROTECTED]> writes:
> > I was wondering if there is a reason that the flex and bison and other
> > generated source files end up in the source directory when doing an
> > out-of-tree build. Would a patch that pu
On Jan 9, 2008 10:00 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Really? I think you've confused some unimplemented decorative syntax
> with what the underlying datatype will or won't do.
Fair enough. The underlying type certainly will do it since it works
without the opt_interval.
> > This is inc
On Thu, 2008-01-10 at 03:06 +0100, Gavin Sherry wrote:
> If the exclusion is executor driven, the planner cannot help but
> create a seq scan plan. The planner will think you're returning 100X
> rows when really you end up returning X rows. After that, all
> decisions made by the planner are totall
On Jan 9, 2008 11:06 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > On Jan 10, 2008 5:00 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> The spec's approach to datetime operations in general is almost totally
> >> brain-dead, ...
>
> > It's true that the spec
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> On Jan 10, 2008 5:00 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> The spec's approach to datetime operations in general is almost totally
>> brain-dead, ...
> It's true that the spec fails to consider DST, in that it doesn't
> partition "day" and "second"
On Jan 9, 2008 10:44 PM, Brendan Jurd <[EMAIL PROTECTED]> wrote:
> On Jan 10, 2008 5:00 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > The spec's approach to datetime operations in general is almost totally
> > brain-dead, and so you won't find a lot of support around here for hewing
> > to the straig
On Jan 10, 2008 5:00 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> The spec's approach to datetime operations in general is almost totally
> brain-dead, and so you won't find a lot of support around here for hewing
> to the straight-and-narrow-spec-compliance approach. If they have not
> even heard of
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> On Jan 10, 2008 2:17 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> You'd have to define exactly what that means, which seems a little
>> tricky for incommensurate intervals. For instance what is the
>> result of '1 month' / '1 day' ?
> Postgres has alread
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED] On Behalf Of Tom Lane
> Sent: Wednesday, January 09, 2008 10:00 PM
> To: Warren Turkal
> Cc: Brendan Jurd; Ilya А. Кovalenko; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] operator suggest " in
"Warren Turkal" <[EMAIL PROTECTED]> writes:
> YEAR TO MONTH and DAY TO {HOUR,MINUTE,SECOND} intervals should not
> combine. PostgreSQL correctly doesn't allow {YEAR,MONTH} TO
> {DAY,HOUR,MINUTE,SECOND} intervals,
Really? I think you've confused some unimplemented decorative syntax
with what the u
"Warren Turkal" <[EMAIL PROTECTED]> writes:
> I was wondering if there is a reason that the flex and bison and other
> generated source files end up in the source directory when doing an
> out-of-tree build. Would a patch that puts those files in the build
> trees be accepted?
Probably not, since
On Jan 9, 2008 9:29 PM, Brendan Jurd <[EMAIL PROTECTED]> wrote:
> Sorry, a correction. The issue of years vs. days isn't ignored. A
> year is just 12 months, which yields 12 * 30 = 360 days, which is
> actually a pretty significant error (1.4% on average).
YEAR TO MONTH and DAY TO {HOUR,MINUTE,S
On Jan 10, 2008 3:33 PM, Brendan Jurd <[EMAIL PROTECTED]> wrote:
> 1 month is deemed equal to 30 days, 1 day is deemed equal to 24 hours
> (although for some reason we ignore the issue of years vs. days).
>
Sorry, a correction. The issue of years vs. days isn't ignored. A
year is just 12 months,
I was wondering if there is a reason that the flex and bison and other
generated source files end up in the source directory when doing an
out-of-tree build. Would a patch that puts those files in the build
trees be accepted?
wt
---(end of broadcast)---
On Jan 9, 2008 8:33 PM, Brendan Jurd <[EMAIL PROTECTED]> wrote:
> I argued in a long-dead thread that we should disallow these kinds of
> comparisons altogether, but I didn't manage to generate much
> enthusiasm. The overall sentiment seemed to be that the slightly
> bogus results were more useful
On Jan 10, 2008 2:17 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> You'd have to define exactly what that means, which seems a little
> tricky for incommensurate intervals. For instance what is the
> result of '1 month' / '1 day' ?
>
Postgres has already made such definitions, to allow direct
interva
Warren Turkal escribió:
> The year to month and day to second intervals should not overlap. The
> standard doesn't actually allow it IIRC.
They do on Postgres anyway. Otherwise the type is not all that useful,
is it?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
Hi Simon,
On Wed, Jan 09, 2008 at 03:08:08PM +, Simon Riggs wrote:
> Do people really "like" running all that DDL? There is significant
> manpower cost in implementing and maintaining a partitioning scheme,
> plus significant costs in getting it wrong.
Well... that's impossible for me to say
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> BTW, if calling pfree() at all here is actually a bug, then we should
> probably fix it in the back branches. It looks more to me like the
> problem was that pg_convert_from was calling pfree() with the wrong
> argument - src_encoding_name instead of
"Tim Yardley" <[EMAIL PROTECTED]> writes:
>> Can you strace the backend while it's doing this and see if there's a
>> difference in the series of kernel calls issued?
> See attached strace. Let me know if you see anything enlightening.
Nope :-(. The strace output is *exactly* the same across al
Hi Simon,
On Wed, Jan 02, 2008 at 05:56:14PM +, Simon Riggs wrote:
> Segment Exclusion
> -
>
> After we note that a segment is read-only we can scan the segment and
> record min/max values for all columns. These are then "implicit
> constraints", which can then be used for seg
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
The case below has just been reported to me. It sure looks odd. I'm
looking into it but any ideas would be welcome. The problem only
occurs if we are updating more than one row.
Pfree'ing something yo
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
The case below has just been reported to me. It sure looks odd. I'm
looking into it but any ideas would be welcome. The problem only occurs
if we are updating more than one row.
Pfree'ing something you didn't palloc is bad n
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> The case below has just been reported to me. It sure looks odd. I'm
> looking into it but any ideas would be welcome. The problem only occurs
> if we are updating more than one row.
Pfree'ing something you didn't palloc is bad news...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 9 Jan 2008 23:52:09 +0100
Gavin Sherry <[EMAIL PROTECTED]> wrote:
te restrictions.
> >
> > Hmm, well if you found declaring the partitions a problem with
> > constraint exclusion it's not going to be any easier using other
> > declarative appr
The year to month and day to second intervals should not overlap. The
standard doesn't actually allow it IIRC.
wt
On Jan 9, 2008 7:17 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Ilya A. Kovalenko" <[EMAIL PROTECTED]> writes:
> > I suggest one more standard date/time operator, to divide one interva
The case below has just been reported to me. It sure looks odd. I'm
looking into it but any ideas would be welcome. The problem only occurs
if we are updating more than one row.
cheers
andrew
andrew=# select getdatabaseencoding();
getdatabaseencoding
-
UTF8
(1 row)
and
On Wed, Jan 09, 2008 at 08:51:30PM +, Simon Riggs wrote:
> > That's what I would have done if it was easier to do with constraint
> > exclusion
> > (did only date partitioning), as the reporting queries will always have
> > some
> > server (stats by services, each service being installed on
On Wed, Jan 09, 2008 at 08:17:41PM +, Simon Riggs wrote:
> On Wed, 2008-01-09 at 20:03 +0100, Gavin Sherry wrote:
>
> > I think Simon's approach is
> > probably more complex from an implementation POV.
>
> Much of the implementation is exactly the same, and I'm sure we agree on
> more than 50
On Wed, Jan 09, 2008 at 02:38:21PM -0500, Chris Browne wrote:
> Ron Mayer <[EMAIL PROTECTED]> writes:
> > Or am I missing something?
>
> Well, this can head in two directions...
>
> 1. Suppose we're not using an "organize in CLUSTER order" approach.
>
> If the data is getting added in roughly "
"Tim Yardley" <[EMAIL PROTECTED]> writes:
> postgres=# select count(*) from pg_timezone_names where utc_offset != '00:00';
> count
> ---
> 0
> postgres=# select count(*) from pg_timezone_names where utc_offset != '00:00';
> count
> ---
>504
> postgres=# select count(*) from pg_ti
On Wed, 2008-01-09 at 21:29 +0100, Dimitri Fontaine wrote:
> Le Wednesday 09 January 2008 19:27:41 Simon Riggs, vous avez écrit :
> > The WHERE clause approach might easily allow more than 2 chunks and they
> > need not be logically contiguous. So the phrase split point doesn't
> > really fit beca
On Tue, 2008-01-08 at 02:12 +, Gregory Stark wrote:
> I also don't understand how this proposal deals with the more common use case
> of unloading and loading data. Normally in partitioned tables we build the
> data in a side table until the data is all correct then load it as a
> partition. I
Hi,
Le Wednesday 09 January 2008 19:27:41 Simon Riggs, vous avez écrit :
> The WHERE clause approach might easily allow more than 2 chunks and they
> need not be logically contiguous. So the phrase split point doesn't
> really fit because it implies a one dimensional viewpoint, but I'm happy
> for
Ron Mayer <[EMAIL PROTECTED]> writes:
> Chris Browne wrote:
>> _On The Other Hand_, there will be attributes that are *NOT* set in a
>> more-or-less chronological order, and Segment Exclusion will be pretty
>> useless for these attributes.
>
> Really?I was hoping that it'd be useful for any d
On Wed, 2008-01-09 at 20:03 +0100, Gavin Sherry wrote:
> I think Simon's approach is
> probably more complex from an implementation POV.
Much of the implementation is exactly the same, and I'm sure we agree on
more than 50% of how this should work already. We just need to close in
on the remainde
Gregory Stark <[EMAIL PROTECTED]> writes:
> So if I write (along with some other joins):
> t1 join t2 on (t1.x=t2.x) where t1.x=3
> I'll get a different result than if I write
> t1, t2 where t1.x=3 and t2.x=3
In 8.3 you won't, because those are in fact exactly equivalent (and the
new Equivalence
Chris Browne wrote:
> _On The Other Hand_, there will be attributes that are *NOT* set in a
> more-or-less chronological order, and Segment Exclusion will be pretty
> useless for these attributes.
Really?I was hoping that it'd be useful for any data
with long runs of the same value repeated
Hackers;
I've noticed a strangeness on our cross-compiled uclibc linked
postgresql package that I was hoping to elicit some help with.
This is probably best described by showing some queries with
commentary, so on with that.
postgres=# select count(*) from pg_timezone_names where utc_offset != '
I wrote:
> A perhaps less invasive idea is to discard any proposed mergeclauses
> that are redundant in this sense. This would still require some
> reshuffling of responsibility between select_mergejoin_clauses and
> the code in pathkeys.c, since right now select_mergejoin_clauses
> takes no accou
"Tom Lane" <[EMAIL PROTECTED]> writes:
> As an example, consider
> t1 join t2 on (...) join t3 on (...) ... join t8 on (...)
> and for simplicity suppose that each ON condition relates the new
> table to the immediately preceding table, and that we can't derive
> any additional join conditio
On Wed, Jan 09, 2008 at 11:47:31AM -0500, Chris Browne wrote:
> [EMAIL PROTECTED] (Simon Riggs) writes:
> > I think we have an opportunity to bypass the legacy-of-thought that
> > Oracle has left us and implement something more usable.
>
> This seems like a *very* good thing to me, from a couple o
On Wed, 2008-01-09 at 18:04 +0100, Markus Schiltknecht wrote:
> > So not convinced of the need for named sections of tables yet. It all
> > seems like detail, rather than actually what we want for managing large
> > tables.
>
> What do you think about letting the database system know the split po
[EMAIL PROTECTED] (Markus Schiltknecht) writes:
> Simon Riggs wrote:
>> With that in mind, can I clarify what you're thinking, please?
>
> Sure, I can try to clarify:
>
>> 2) the things you've been discussing are essential requirements of
>> partitioning and we could never consider it complete unti
[EMAIL PROTECTED] (Simon Riggs) writes:
> I think we have an opportunity to bypass the legacy-of-thought that
> Oracle has left us and implement something more usable.
This seems like a *very* good thing to me, from a couple of
perspectives.
1. I think you're right on in terms of the issue of th
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Alvaro Herrera" <[EMAIL PROTECTED]> writes:
>> Would it be a good idea to keep removing redundant clauses and rethink
>> the preference for clauseful joins, going forward?
> I don't understand what's going on here. The planner is choosing one join
> ord
On Wed, 2008-01-09 at 17:30 +0100, Markus Schiltknecht wrote:
> Simon Riggs wrote:
> > With that in mind, can I clarify what you're thinking, please?
>
> Sure, I can try to clarify:
>
> > 2) the things you've been discussing are essential requirements of
> > partitioning and we could never consi
Hi,
Simon Riggs wrote:
When I delete all rows WHERE some_date < 'cut-off date' on a segment
boundary value that would delete all segments that met the criteria. The
following VACUUM will then return those segments to be read-write, where
they can then be refilled with new incoming data. The only
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>
>> Comparing the behavior of this to my patch for HEAD, I am coming to the
>> conclusion that this is actually a *better* planning method than
>> removing the redundant join conditions, even when they're truly
>> rendundant! The rea
Hi,
Gregory Stark wrote:
That's an interesting thought. I think your caveats are right but with some
more work it might be possible to work it out. For example if a background
process processed the WAL and accumulated an array of possibly-dead tuples to
process in batch. It would wait whenever i
Hi,
Simon Riggs wrote:
With that in mind, can I clarify what you're thinking, please?
Sure, I can try to clarify:
2) the things you've been discussing are essential requirements of
partitioning and we could never consider it complete until they are also
included and we must therefore talk ab
On Wed, 2008-01-09 at 15:10 +, Gregory Stark wrote:
> The goal should be to improve vacuum, then
> adjust the autovacuum_scale_factor as low as we can. As vacuum gets
> cheaper the scale factor can go lower and lower. We shouldn't allow
> the existing autovacuum behaviour to control the way va
On Wed, 2008-01-09 at 15:53 +, Gregory Stark wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> Perhaps a good analogy is indexes. Index names are themselves kind of
> redundant and people usually use names which encode up most of the information
> of the definition.
>
> But the reason you
On Wed, 2008-01-09 at 16:20 +0100, Markus Schiltknecht wrote:
> Simon Riggs wrote:
> >> I have to admit I always found it kludgy to have objects named
> >> invoices_2000_JAN and invoices_2000_FEB and so on. It's kind of an meta
> >> denormalization. But so is specifying where clauses repeatedly.
>
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Wed, 2008-01-09 at 02:25 +, Gregory Stark wrote:
>
>> Without naming the DBA would have to specify the same ranges every time he
>> wants to change the properties. He might do a "SET read_only WHERE created_on
>> < '2000-01-01'" one day then anoth
On Wed, 2008-01-09 at 10:15 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Not sure why this hasn't being applied yet for 8.3
>
> Because it doesn't fix the problem ... which is that the postmaster
> kills the archiver (and the stats collector too) at what is now the
> wrong
Simon Riggs wrote:
I have to admit I always found it kludgy to have objects named
invoices_2000_JAN and invoices_2000_FEB and so on. It's kind of an meta
denormalization. But so is specifying where clauses repeatedly.
The idea for using the WHERE clauses was to specifically avoid naming.
I un
"Ilya A. Kovalenko" <[EMAIL PROTECTED]> writes:
> I suggest one more standard date/time operator, to divide one interval
> by another with numeric (or float, for example) result.
You'd have to define exactly what that means, which seems a little
tricky for incommensurate intervals. For instance w
Simon Riggs <[EMAIL PROTECTED]> writes:
> Not sure why this hasn't being applied yet for 8.3
Because it doesn't fix the problem ... which is that the postmaster
kills the archiver (and the stats collector too) at what is now the
wrong point in the shutdown sequence.
regar
"Markus Schiltknecht" <[EMAIL PROTECTED]> writes:
> Hi,
>
> Gokulakannan Somasundaram wrote:
>> If we can ask the Vacuum process to scan the WAL log, it can get all the
>> relevant details on where it needs to go.
That's an interesting thought. I think your caveats are right but with some
more w
Gavin and all,
This is quite a long reply, so apologies for that.
On Wed, 2008-01-09 at 07:28 +0100, Gavin Sherry wrote:
> On Wed, Jan 02, 2008 at 05:56:14PM +, Simon Riggs wrote:
> > This technique would be useful for any table with historical data keyed
> > by date or timestamp. It would al
On Wed, 2008-01-09 at 02:25 +, Gregory Stark wrote:
> "Markus Schiltknecht" <[EMAIL PROTECTED]> writes:
>
> > There are two very distinct ways to handle partitioning. For now, I'm
> > calling
> > them named and unnamed partitioning.
> The naming is precisely the useful part in that it is ho
On Sat, 2008-01-05 at 16:42 +0100, Markus Schiltknecht wrote:
> Simon Riggs wrote:
> > On Fri, 2008-01-04 at 22:26 +0100, Markus Schiltknecht wrote:
> >
> >> I'm still puzzled about how a DBA is expected to figure out which
> >> segments to mark. Simon, are you assuming we are going to pass on
On Wed, 2008-01-09 at 00:22 -0500, Tom Lane wrote:
> pgsql-core wasted quite a lot of time
Core's efforts are appreciated by all, so not time wasted.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
---(end of broadcast)---
TIP 6: expla
Simon Riggs wrote:
Hmmm. I think it fits rather neatly with BitmapIndexScans. It would be
easy to apply the index condition and/or filters to see which segments
are excluded and then turn off bits in the bitmap appropriately.
Yeah, good point.
Not fully sure about IndexScans yet. I don't thin
> So it's easily possible having more dead tuples, than live ones. In such
> cases, scanning the WAL can easily takes *longer* than scanning the
> table, because the amount of WAL to read would be bigger.
Yes... i made a wrong assumption there.. so the idea is totally
useless.
Thanks,
Goku
On Mon, 2008-01-07 at 14:20 +0100, Markus Schiltknecht wrote:
> AFAIUI, Segment Exclusion combines perfectly well with
> clustering.
Yes, seems like it would be possible to have a segment-aware CLUSTER, so
it was actually usable on large tables. Not planning that initially
though.
--
Simon
On Sun, 2008-01-06 at 11:39 +0100, Markus Schiltknecht wrote:
> I think this has to do with SE not being of much use for index scans.
Hmmm. I think it fits rather neatly with BitmapIndexScans. It would be
easy to apply the index condition and/or filters to see which segments
are excluded and the
On Mon, 2008-01-07 at 12:14 +0100, Csaba Nagy wrote:
> On Wed, 2008-01-02 at 17:56 +, Simon Riggs wrote:
> > Like it?
>
> Very cool :-)
Thanks. As ever, a distillation of various thoughts, not all mine.
> One additional thought: what about a kind of "segment fill factor" ?
> Meaning: each se
Andrew Dunstan wrote:
Smells suspiciously like an rpath problem to me. What are your configure
settings?
Ah, yeah, I see. Using something else than --prefix=/usr helped.
Thanks for the hint!
Regards
Markus
---(end of broadcast)---
TIP 5: don'
Markus Schiltknecht wrote:
Hi,
I'm trying to run 'make check' on a 64bit Debian unstable. That aborts
after 60 seconds due to not being able to connect to the postmaster.
I figured that there's nothing wrong with the postmaster, rather psql
can't start up, because it gets linked against an
am Wed, dem 09.01.2008, um 17:33:00 +0700 mailte Ilya A. Kovalenko folgendes:
>
> I suggest one more standard date/time operator, to divide one interval
> by another with numeric (or float, for example) result.
> I.e. something like that:
>
> database=# SELECT '5400 seconds'::interval / '1 hour'
Hi,
I'm trying to run 'make check' on a 64bit Debian unstable. That aborts
after 60 seconds due to not being able to connect to the postmaster.
I figured that there's nothing wrong with the postmaster, rather psql
can't start up, because it gets linked against an older libpq.so.5. It
looks l
On Sat, 2008-01-05 at 16:30 -0500, Robert Treat wrote:
> I'm not following this. If we can work out a scheme, I see no reason not to
> allow a single table to span multiple tablespaces.
That seems to be something we might want anyway, so yes.
> The difference is that, if I currently have a ta
Hi,
Gokulakannan Somasundaram wrote:
If we can ask the Vacuum process to scan
the WAL log, it can get all the relevant details on where it needs to
go.
You seem to be assuming that only few tuples have changed between
vacuums, so that WAL could quickly guide the VACUUM processes to the
area
Thanks for the explanation on the ulimits; I can see how that could turn
out a problem in some cases.
Following Tom's suggestion, here is the startup script I used:
#!/bin/sh
ulimit -a > $PGHOST/server.ulimit
pg_ctl start -l $PGHOST/server.log
The ulimits seem to be the same, though:
$> cat ser
Hi,
May be i am reposting something which has been discussed to end in this
forum. I have made a search in the archives and i couldn't find any
immediately.
With my relatively small experience in Performance Testing and Tuning,
one of the rules of thumb for getting Performance is "Don't do
I suggest one more standard date/time operator, to divide one interval
by another with numeric (or float, for example) result.
I.e. something like that:
database=# SELECT '5400 seconds'::interval / '1 hour'::interval;
?column?
--
1.5
(1 row)
Ilya A. Kovalenko
--
On Sat, 2008-01-05 at 12:09 +, Simon Riggs wrote:
> On Fri, 2008-01-04 at 17:28 +0900, Fujii Masao wrote:
> > Simon Riggs wrote:
> >
> > > My original one line change described on bug 3843 seems like the best
> > > solution for 8.3.
> > >
> >
> > +1
> > Is this change in time for RC1?
>
> P
Sorry for previous message having no comments.
Just remark:
These aggregates created successfuly both in 8.2 and 8.3beta4:
CREATE AGGREGATE array_concat(anyarray) (
SFUNC=array_cat,
STYPE=anyarray
);
CREATE AGGREGATE array_build(anyelement) (
SFUNC=array_append,
STYPE=anyarray
);
But aggregate
So...in the vein of my last mail, I have tried to create another patch
for refactoring out some of the HAVE_INT64_TIMESTAMP ifdefs in the
code in timestamp.c. I have attached the patch. Please let me know if
this patch is acceptable and what I can do to continue this effort.
Thanks,
wt
From 77db4f
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Did you want me to work on this? I could probably put some time into it
this coming weekend.
I'll try to get to it before that --- if no serious bugs come up this
week, core is thinking of wrapping 8.3.0 at the end of the week, so
On Tue, Jan 08, 2008 at 05:33:51PM -0500, Merlin Moncure wrote:
> Here is a short example which demonstrates some of the major features.
> There are many other examples and discussions of minutia in the
> documentation.
I havn't looked at the source but FWIW I think it's an awesome idea.
Have a
83 matches
Mail list logo
