On May 4, 2007, at 10:13 PM, Nathan Buchanan wrote:
Hello!
I have a potential situation where I will have a lot of sensor data
coming in very often. (every second or so) The sensor data is from
physics type measurements, and will normally follow a slowly
changing pattern with sinusoidal
Hello!
I have a potential situation where I will have a lot of sensor data coming
in very often. (every second or so) The sensor data is from physics type
measurements, and will normally follow a slowly changing pattern with
sinusoidal disturbances. The overall shape of the data is more important
Andrew Dunstan wrote:
> I will say publicly what I have said to others privately. Forgive me if
> I'm a bit blunter than usual. I do not see any value in this at all.
> What we need to track are problems to be solved, be they bugs or
> features, not particular patches. Tracking patches simply co
Bruce Momjian wrote:
I have already responded to all the email comments. Here is my idea of
moving forward. There are basically three interrelated issues:
1) bug tracking
2) getting more people to review complex patches
3) patch tracking
I am not going to go into #1, except to say that
I have already responded to all the email comments. Here is my idea of
moving forward. There are basically three interrelated issues:
1) bug tracking
2) getting more people to review complex patches
3) patch tracking
I am not going to go into #1, except to say that the problem has always
be
Josh Berkus wrote:
> Bruce,
>
> > Get rid of gborg and let's talk.
>
> Touche'.
>
> Actually, AFAICT, the only active thing left on GBorg is WWW. If we move
> that, we can shut it down. Any objections?
>
> > Why am I having to spend hours in Syndey saying the same thing? ?Why
> > don't you g
Csaba Nagy wrote:
> On Thu, 2007-05-03 at 13:51, Bruce Momjian wrote:
> > I believe the problem is not that there isn't enough information, but
> > not enough people able to do the work. Seeking solutions in areas that
> > aren't helping was the illustration.
>
> Yes Bruce, but you're failing to
Awhile back I wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> FWIW, is the attached patch about what you had in mind? (It probably only
>> covers "normal" types at the moment.)
> Hm, I hadn't realized that it would take as little work as that ...
> I have an itchy feeling that you misse
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > If you're saying we don't currently warn if a revoke leaves the
> > priviledges in-tact for the right and target, I'm not sure you can
> > currently get in a state where it'd be possible to run into that.
>
> I'm
Based on the discussion so far, it seems to me that the sane course of
action is to continue to register the grantor, because the standard
mandates that it should be there; but ignore the parts where we revoke
selectively, because that's a stupid thing to do. So we do deviate, if
slightly.
So we
Stephen Frost <[EMAIL PROTECTED]> writes:
> If you're saying we don't currently warn if a revoke leaves the
> priviledges in-tact for the right and target, I'm not sure you can
> currently get in a state where it'd be possible to run into that.
I'm thinking of the case that comes up periodically w
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > Hmm. I'm not sure, but that may have been a case where it was generally
> > decided that the spec was somewhat braindead in this fashion (it seems
> > so in my personal view of this, honestly...). To issue a rev
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> Guillaume Smet wrote:
>> On 5/4/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>>> Sort Method: disk Memory: 1000KB Disk: 18482KB
>>
>> +1 for this one.
> I like that one too ...
OK, in the event it looks like one of these four messages:
"S
Stephen Frost <[EMAIL PROTECTED]> writes:
> Hmm. I'm not sure, but that may have been a case where it was generally
> decided that the spec was somewhat braindead in this fashion (it seems
> so in my personal view of this, honestly...). To issue a revoke and
> have it not work would be kind of co
* Alvaro Herrera ([EMAIL PROTECTED]) wrote:
> Ah, here it is, 12.7 . It says that if role revokes
> another role from a third role, it will only remove the privileges that
> were granted by him, not someone else.
Hmm. I'm not sure, but that may have been a case where it was generally
decided tha
Alvaro Herrera wrote:
> Stephen Frost wrote:
>
> > I don't have time right at the moment (leaving shortly and will be gone
> > all weekend) but what I would do is check the SQL standard, especially
> > the information schema, for any requirement to track the grantor. Much
> > of what I did was ba
Stephen Frost wrote:
> I don't have time right at the moment (leaving shortly and will be gone
> all weekend) but what I would do is check the SQL standard, especially
> the information schema, for any requirement to track the grantor. Much
> of what I did was based on the standard so that may ha
* Alvaro Herrera ([EMAIL PROTECTED]) wrote:
> I took a look, and concluded that the only bit of code that uses the
> grantor at all is pg_dumpall.
>
> Does this means we can remove it altogether? In back branches, we would
> take out the pg_dumpall code.
I don't have time right at the moment (le
Tom,
Did you restart Postgres and drop file system caches?
What I am suspecting is that some sort of prefetching is happening.
I know that Postgres does not do prefetching.
I also understand very little about OS/FileSystem level prefetching.
- Original Message
From: Tom Lane <[EMAIL P
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> >> Why is it that we record grantor at all? One could argue that granting
> >> membership in a role is done on behalf of that role and there's no real
> >> need to remember exactly who did it.
>
> > I think you should ask Stephen Fro
Guillaume Smet wrote:
> On 5/4/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Sort Method: disk Memory: 1000KB Disk: 18482KB
>
> +1 for this one.
I like that one too ...
Stefan
---(end of broadcast)---
TIP 1: if posting/reading through Use
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> Is it possible to have something like Sort (disk|top-N|memory) instead
> of Sort?
That would be sane if the decision were fixed at plan time, but it isn't.
What do you think of the add-a-line approach?
regards, tom lane
-
On 5/4/07, Tom Lane <[EMAIL PROTECTED]> wrote:
Sort Method: disk Memory: 1000KB Disk: 18482KB
+1 for this one.
--
Guillaume
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-
I think this is the apprach joshua tried the first time and it backfired... I
think we need a more personal approach. I'm willing to put time into this if
people want a new point man (I don't think Joshua will mind, lmk if you do)
but it will have to wait untill after pgcon.
On Thursday 03 Ma
On 5/4/07, Tom Lane <[EMAIL PROTECTED]> wrote:
No, you can turn on trace_sort and track it from watching the log.
If pgfouine hasn't got something for that already, I'd be surprised.
Well, it hasn't. I never used trace_sort so i didn't think of
implementing something to use it. I'll take a look
On 5/4/07, Tom Lane <[EMAIL PROTECTED]> wrote:
-> Sort (cost=840.19..865.19 rows=1 width=244) (actual
time=140.492..140.880 rows=100 loops=1 method=top-N)
Sort K
Josh Berkus wrote:
Tom, Pavel,
Hmm, I see your point. I'm personally satisfied with adding a new
proargmode to solve this as you suggest.
This will break client-side code that looks at proargmode, and I don't
think the argument in favor is strong enough to justify that ...
What kind of clien
Jim Nasby <[EMAIL PROTECTED]> writes:
> If the method is disk it would be nice to know how much spilled to
> disk. That would tell you if it would be worth increasing work_mem,
> and by how much.
Well, a more radical proposal is to add a whole 'nother line to the
output, which would give us ro
On Wednesday 02 May 2007 01:19, Tom Lane wrote:
> Josh Berkus <[EMAIL PROTECTED]> writes:
> > Actually, that can happen with the current system. The real blocker there
> > is that some people, particularly Tom, work so fast that there's no
> > chance for a new reviewer to tackle the easy stuff. Ma
> > What do you think the output should look like? The first thought that
> > comes to mind is to add "method=memory" (or disk or top-N) to the
> > "actual" annotation:
Having the "disk" and "memory" would be really useful too.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
-
Jim Nasby <[EMAIL PROTECTED]> writes:
> On a related note, it would also be *really* nice if we kept stats on
> how many sorts or hashes had spilled to disk, perhaps along with how
> much had spilled. Right now the only way to monitor that in a
> production system is to setup a cron job to wa
Tom, Pavel,
> > Hmm, I see your point. I'm personally satisfied with adding a new
> > proargmode to solve this as you suggest.
>
> This will break client-side code that looks at proargmode, and I don't
> think the argument in favor is strong enough to justify that ...
What kind of client-side cod
On May 4, 2007, at 7:08 PM, Tom Lane wrote:
What do you think the output should look like? The first thought that
comes to mind is to add "method=memory" (or disk or top-N) to the
"actual" annotation:
regression=# explain analyze select * from tenk1 order by fivethous
limit 100;
> >> It's not exactly easy to do, because (a) none of this information
> >> is exposed outside tuplesort.c, and (b) the tuplesortstate object
> >> is probably gone by the time EXPLAIN ANALYZE runs, anyway.
>
> > Hmm. Ok. Don't know enough about those parts of the code to comment on
> > that, but I
Paul Ramsey <[EMAIL PROTECTED]> writes:
> Just take 150-199, and submit a patch to HACKERS to updates the comment
> in pg_statistic appropriately. I am sure the it will be some time before
> we invent another 49 kinds of selectivity statistic.
I've been on the wrong wavelength in this whole thre
Magnus Hagander <[EMAIL PROTECTED]> writes:
> On Fri, May 04, 2007 at 12:38:18PM -0400, Tom Lane wrote:
>> Magnus Hagander <[EMAIL PROTECTED]> writes:
>>> Could we show it in EXPLAIN ANALYZE somehow? I'm thinking it would be good
>>> to see at runtime (for example as a hint that if you put in a bit
Just take 150-199, and submit a patch to HACKERS to updates the comment
in pg_statistic appropriately. I am sure the it will be some time before
we invent another 49 kinds of selectivity statistic.
P
Ale Raza wrote:
Tom,
What numbers you can reserve for our geometry type, 200 - 299?
Ale.
-
Martijn van Oosterhout wrote:
> On Fri, May 04, 2007 at 02:18:31PM +0200, Zdenek Kotala wrote:
> > Is the reason for keeping this in a code? Another kind of construct is:
> >
> > #define PG_RETURN_NULL() \
> > do { fcinfo->isnull = true; return (Datum) 0; } while (0)
>
> This is a standard w
On Fri, May 04, 2007 at 02:18:31PM +0200, Zdenek Kotala wrote:
> Is the reason for keeping this in a code? Another kind of construct is:
>
> #define PG_RETURN_NULL() \
> do { fcinfo->isnull = true; return (Datum) 0; } while (0)
This is a standard way of getting multiple statements into a mac
Zdenek Kotala wrote:
Tom Lane wrote:
We can fix this for gcc by putting __attribute__((noreturn)) on the
declaration of pg_re_throw(), but what about other compilers?
Sun studio also complains about it :(.
I'm sorry it was to late for me, I recheck it again and Sun studio is
happy :-) and
On 4/25/07, Pavel Stehule <[EMAIL PROTECTED]> wrote:
for me RETURNS TABLE (a,b) isn't equialent for (OUT a, OUT b) RETURNS SETOF
RECORD, but
it's eq. for RETURNS SETOF RECORD ... and SELECT FROM foo() AS (a, b).
Reason:
example: I have table with attr. cust_id, and I want to use parametrized
vi
2007/5/3, Tom Lane <[EMAIL PROTECTED]>:
Neil Conway <[EMAIL PROTECTED]> writes:
> Pavel, my apologies for not getting back to you sooner.
> On Wed, 2007-25-04 at 07:12 +0200, Pavel Stehule wrote:
>> example: I have table with attr. cust_id, and I want to use parametrized
>> view (table function)
42 matches
Mail list logo
