public inbox for [email protected]
help / color / mirror / Atom feed[PATCH 2/2] Allow composite types in bootstrap
7+ messages / 4 participants
[nested] [flat]
* [PATCH 2/2] Allow composite types in bootstrap
@ 2020-11-17 15:28 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 7+ messages in thread
From: Justin Pryzby @ 2020-11-17 15:28 UTC (permalink / raw)
---
src/backend/bootstrap/bootstrap.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/src/backend/bootstrap/bootstrap.c b/src/backend/bootstrap/bootstrap.c
index 1b940d9d27..a0fcbb3d83 100644
--- a/src/backend/bootstrap/bootstrap.c
+++ b/src/backend/bootstrap/bootstrap.c
@@ -916,6 +916,7 @@ gettype(char *type)
{
if (Typ != NIL)
{
+ static bool did_reread PG_USED_FOR_ASSERTS_ONLY = false; /* Already reread pg_types? */
ListCell *lc;
foreach (lc, Typ)
@@ -927,6 +928,33 @@ gettype(char *type)
return app->am_oid;
}
}
+
+ /*
+ * The type wasn't known; check again to handle composite
+ * types, added since first populating Typ.
+ */
+
+ /*
+ * Once all the types are populated and we handled composite
+ * types, shouldn't need to do that again.
+ */
+ Assert(!did_reread);
+ did_reread = true;
+
+ list_free_deep(Typ);
+ Typ = NIL;
+ populate_typ();
+
+ /* Need to avoid infinite recursion... */
+ foreach (lc, Typ)
+ {
+ struct typmap *app = lfirst(lc);
+ if (strncmp(NameStr(app->am_typ.typname), type, NAMEDATALEN) == 0)
+ {
+ Ap = app;
+ return app->am_oid;
+ }
+ }
}
else
{
--
2.17.0
--yQbNiKLmgenwUfTN--
^ permalink raw reply [nested|flat] 7+ messages in thread
* DBT-5 Stored Procedure Development (2022)
@ 2022-04-19 18:01 Mahesh Gouru <[email protected]>
2022-04-19 18:30 ` Re: DBT-5 Stored Procedure Development (2022) Mark Wong <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Mahesh Gouru @ 2022-04-19 18:01 UTC (permalink / raw)
To: pgsql-hackers
Dear all,
Please review the attached for my jerry-rigged project proposal. I am
seeking to continually refactor the proposal as I can!
Thanks,
Mahesh
Attachments:
[application/pdf] GSoC (2022) - Proposal for PostgreSQL-Gouru.pdf (89.7K, ../../CA+VzgBOVQbQkFxvzgGcYW6_vLGj39=u9X=XAxw_2axR2pQd6vw@mail.gmail.com/3-GSoC%20%282022%29%20-%20Proposal%20for%20PostgreSQL-Gouru.pdf)
download
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: DBT-5 Stored Procedure Development (2022)
2022-04-19 18:01 DBT-5 Stored Procedure Development (2022) Mahesh Gouru <[email protected]>
@ 2022-04-19 18:30 ` Mark Wong <[email protected]>
2022-04-20 00:20 ` Re: DBT-5 Stored Procedure Development (2022) Peter Geoghegan <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Mark Wong @ 2022-04-19 18:30 UTC (permalink / raw)
To: Mahesh Gouru <[email protected]>; +Cc: pgsql-hackers
Hi Mahesh,
On Tue, Apr 19, 2022 at 02:01:54PM -0400, Mahesh Gouru wrote:
> Dear all,
>
> Please review the attached for my jerry-rigged project proposal. I am
> seeking to continually refactor the proposal as I can!
My comments might briefer that they should be, but I need to write this
quickly. :)
* The 4 steps in the description aren't needed, they already exist.
* May 20: I think this should be more about reviewing the TPC-E
specification rather than industry research, as we want to try to
follow specification guidelines.
* June 20: Random data generation and scaling are provided by and
already defined by the spec
* Aug 01: A report generator already exists, but I think time could be
allocated to redoing the raw HTML generation with something like
reStructuredText, something that is easier to generate with scripts
and convertible into other formats with other tools
As some of tasks proposed are actually in place, one other task could be
updating egen (the TPC supplied code.) The kit was last developed again
1.12 and 1.14 is current as this email.
Regards,
Mark
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: DBT-5 Stored Procedure Development (2022)
2022-04-19 18:01 DBT-5 Stored Procedure Development (2022) Mahesh Gouru <[email protected]>
2022-04-19 18:30 ` Re: DBT-5 Stored Procedure Development (2022) Mark Wong <[email protected]>
@ 2022-04-20 00:20 ` Peter Geoghegan <[email protected]>
2022-04-26 17:36 ` Re: DBT-5 Stored Procedure Development (2022) Mark Wong <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Peter Geoghegan @ 2022-04-20 00:20 UTC (permalink / raw)
To: Mark Wong <[email protected]>; +Cc: Mahesh Gouru <[email protected]>; pgsql-hackers
On Tue, Apr 19, 2022 at 11:31 AM Mark Wong <[email protected]> wrote:
> As some of tasks proposed are actually in place, one other task could be
> updating egen (the TPC supplied code.) The kit was last developed again
> 1.12 and 1.14 is current as this email.
As you know, I have had some false starts with using DBT5 on a modern
Linux distribution. Perhaps I gave up too easily at the time, but I'm
definitely still interested. Has there been work on that since?
Thanks
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: DBT-5 Stored Procedure Development (2022)
2022-04-19 18:01 DBT-5 Stored Procedure Development (2022) Mahesh Gouru <[email protected]>
2022-04-19 18:30 ` Re: DBT-5 Stored Procedure Development (2022) Mark Wong <[email protected]>
2022-04-20 00:20 ` Re: DBT-5 Stored Procedure Development (2022) Peter Geoghegan <[email protected]>
@ 2022-04-26 17:36 ` Mark Wong <[email protected]>
2022-04-26 17:44 ` Re: DBT-5 Stored Procedure Development (2022) Peter Geoghegan <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Mark Wong @ 2022-04-26 17:36 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: Mahesh Gouru <[email protected]>; pgsql-hackers
On Tue, Apr 19, 2022 at 05:20:50PM -0700, Peter Geoghegan wrote:
> On Tue, Apr 19, 2022 at 11:31 AM Mark Wong <[email protected]> wrote:
> > As some of tasks proposed are actually in place, one other task could be
> > updating egen (the TPC supplied code.) The kit was last developed again
> > 1.12 and 1.14 is current as this email.
>
> As you know, I have had some false starts with using DBT5 on a modern
> Linux distribution. Perhaps I gave up too easily at the time, but I'm
> definitely still interested. Has there been work on that since?
I'm afraid not. I'm guessing that pulling in egen 1.14 would address
that. Maybe it would make sense to put that on the top of todo list if
this project is accepted...
Regards,
Mark
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: DBT-5 Stored Procedure Development (2022)
2022-04-19 18:01 DBT-5 Stored Procedure Development (2022) Mahesh Gouru <[email protected]>
2022-04-19 18:30 ` Re: DBT-5 Stored Procedure Development (2022) Mark Wong <[email protected]>
2022-04-20 00:20 ` Re: DBT-5 Stored Procedure Development (2022) Peter Geoghegan <[email protected]>
2022-04-26 17:36 ` Re: DBT-5 Stored Procedure Development (2022) Mark Wong <[email protected]>
@ 2022-04-26 17:44 ` Peter Geoghegan <[email protected]>
2022-05-02 14:30 ` Re: DBT-5 Stored Procedure Development (2022) Mark Wong <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Peter Geoghegan @ 2022-04-26 17:44 UTC (permalink / raw)
To: Mark Wong <[email protected]>; +Cc: Mahesh Gouru <[email protected]>; pgsql-hackers
On Tue, Apr 26, 2022 at 10:36 AM Mark Wong <[email protected]> wrote:
> I'm afraid not. I'm guessing that pulling in egen 1.14 would address
> that. Maybe it would make sense to put that on the top of todo list if
> this project is accepted...
Wouldn't it be a prerequisite here? I don't actually have any reason
to prefer the old function-based code to the new stored procedure
based code. Really, all I'm looking for is a credible implementation
of TPC-E that I can use to model some aspects of OLTP performance for
my own purposes.
TPC-C (which I have plenty of experience with) has only two secondary
indexes (in typical configurations), and doesn't really stress
concurrency control at all. Plus there are no low cardinality indexes
in TPC-C, while TPC-E has quite a few. Chances are high that I'd learn
something from TPC-E, which has all of these things -- I'm really
looking for bottlenecks, where Postgres does entirely the wrong thing.
It's especially interesting to me as somebody that focuses on B-Tree
indexing.
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: DBT-5 Stored Procedure Development (2022)
2022-04-19 18:01 DBT-5 Stored Procedure Development (2022) Mahesh Gouru <[email protected]>
2022-04-19 18:30 ` Re: DBT-5 Stored Procedure Development (2022) Mark Wong <[email protected]>
2022-04-20 00:20 ` Re: DBT-5 Stored Procedure Development (2022) Peter Geoghegan <[email protected]>
2022-04-26 17:36 ` Re: DBT-5 Stored Procedure Development (2022) Mark Wong <[email protected]>
2022-04-26 17:44 ` Re: DBT-5 Stored Procedure Development (2022) Peter Geoghegan <[email protected]>
@ 2022-05-02 14:30 ` Mark Wong <[email protected]>
0 siblings, 0 replies; 7+ messages in thread
From: Mark Wong @ 2022-05-02 14:30 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: Mahesh Gouru <[email protected]>; pgsql-hackers
On Mon, May 02, 2022 at 07:14:28AM -0700, Mark Wong wrote:
> On Tue, Apr 26, 2022, 10:45 AM Peter Geoghegan <[email protected]> wrote:
>
> > On Tue, Apr 26, 2022 at 10:36 AM Mark Wong <[email protected]> wrote:
> > > I'm afraid not. I'm guessing that pulling in egen 1.14 would address
> > > that. Maybe it would make sense to put that on the top of todo list if
> > > this project is accepted...
> >
> > Wouldn't it be a prerequisite here? I don't actually have any reason
> > to prefer the old function-based code to the new stored procedure
> > based code. Really, all I'm looking for is a credible implementation
> > of TPC-E that I can use to model some aspects of OLTP performance for
> > my own purposes.
> >
> > TPC-C (which I have plenty of experience with) has only two secondary
> > indexes (in typical configurations), and doesn't really stress
> > concurrency control at all. Plus there are no low cardinality indexes
> > in TPC-C, while TPC-E has quite a few. Chances are high that I'd learn
> > something from TPC-E, which has all of these things -- I'm really
> > looking for bottlenecks, where Postgres does entirely the wrong thing.
> > It's especially interesting to me as somebody that focuses on B-Tree
> > indexing.
I think it could be done in either order.
While it's not ideal that the kit seems to work most reliably as-is on
RHEL/Centos/etc. 6, I think that could provide some confidence in
getting familiar with something on a working platform. The updates to
the stored functions/procedures would be the same regardless of egen
version.
If we get the project slot, we can talk further about what to actually
tackle first.
Regards,
Mark
^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2022-05-02 14:30 UTC | newest]
Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-11-17 15:28 [PATCH 2/2] Allow composite types in bootstrap Justin Pryzby <[email protected]>
2022-04-19 18:01 DBT-5 Stored Procedure Development (2022) Mahesh Gouru <[email protected]>
2022-04-19 18:30 ` Re: DBT-5 Stored Procedure Development (2022) Mark Wong <[email protected]>
2022-04-20 00:20 ` Re: DBT-5 Stored Procedure Development (2022) Peter Geoghegan <[email protected]>
2022-04-26 17:36 ` Re: DBT-5 Stored Procedure Development (2022) Mark Wong <[email protected]>
2022-04-26 17:44 ` Re: DBT-5 Stored Procedure Development (2022) Peter Geoghegan <[email protected]>
2022-05-02 14:30 ` Re: DBT-5 Stored Procedure Development (2022) Mark Wong <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox